Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
so 30 minutes is a really aggressive timeframe to introduce a group of people that doesn't really have much context for this so I'm gonna maybe go a little fast maybe hopefully not too fast but also there's a you should think of this talk as a
starting off point a jumping-off point for your in interest in rust if you become interested and maybe there will be a few things here and there that you could sort of jump off and use or look into I'm gonna be writing a blog post over the next few weeks
I think that talks about how you specifically integrate rust into a Ruby or rails application and I'm not gonna talk about that today because that's kind of its whole other talk but I think if you really if you leave this talk thinking that you really
want to use rust for something real that's probably gonna be the best way for you to do that so keep an eye out for on the skylight blog we'll be talking about it yeah what's up with that so I think the way a lot of people look at programming languages
is with this sort of quadrant grid you can see that when they announce Swift Apple created this quadrant grid and among despite the fact that it's really silly like I don't think Ruby is faster and more performant and more performant than JavaScript
and I don't really I don't understand any of it really but I think people do think of the world in terms of these quadrants and I think if I was gonna give a talk about rust and I wasn't me probably I would also make one of these quadrant diagrams
and try to stick rust in one of the quadrants and for me I am showing this because I think it's kind of a bad way to think about program programs and programming in general and the reason for that is that in programming really the only thing that is that
stays the same is change the only constant is change and what that means is that a lot of people have this fixed picture in their head of this trade-off between performance and productivity and they imagine that that trade-off is kind of fixed so if you gain
a little more productivity then surely what that means is that you've traded off some performance but if you look at reality you look at reality and this is let's say 2005 you'll see okay there's the programming language JavaScript which didn't
have that logo at the time it was a reasonably productive programming language it was a dynamic language maíam does not very fast and then if you were gonna look at that diagram and fast forward 10 years obviously javascript hasn't improved it's it
hasn't really changed that much in terms of productivity it hasn't gotten maybe it's gotten a little bit better but for the most part the language that most people write today is the same language the most people wrote ten years ago so if you were
gonna think about things as just a trade-off between productivity and performance you would expect well of course JavaScript hasn't gotten any hasn't become worse than productivity so that means it must not have gotten faster but of course what actually
happened during that time is that javascript got a little bit more productive with es5 and some es6 features and a lot faster and really in in reality every language that has that sticks around for any period of time tries to figure out ways to improve productivity
without reducing performance over time which means that every single language is always moving you it looks like you should have to go down and to the right but really every language going up into the right and when the language changes enough or when a new
language comes out that is sufficiently different from other languages it enables a whole new generation of people to do something that they couldn't do before and I think you javascript is really good example this right JavaScript was really a slow language
to begin with but when JavaScript got fast and when it got a little more productive and when the ergonomics of using it on the server got better it enabled a whole generation of front-end developers to write back-end code and I think you could you could say
oh well I don't want my jQuery developer writing back-end code you can say that all you want but the reality is that if you're looking at the quadrant you missed these shifts these changes in the programming landscape that enables whole generations
of people large groups of people to do something that they weren't able to do before and rust is sort of trying to do a similar thing right so Russ is a new language but rust is also trying to enable people who might not have been willing to do something
before or might not be able to do something for it to do something now and just to give you a high-level sense of what's going on here before Russ there were essentially two kinds of languages there were languages that were safe and what I mean by safe
is that if you write a program in the programming language and there's no bugs in the compiler or the interpreter your program cannot have a seg fault right so whenever that happens to you in Ruby what that means is that there's some C code involved
it's not Ruby giving you the seg fault it's some C code giving it a seg fault and that's a guarantee if you write in Ruby or you write in Python you're writing go because there's a garbage collector in those programming languages you're
guaranteed that if you write code will not get a seg fault and then there's other languages C C++ and a few other languages of that oak that give you direct control over where you can put your memory and that correct control gives you the ability to get
better performance better memory usage and all that but the trade-off of that is that if you make a little mistake if you slip up a little bit and everybody knows who's ever tried to work with C or C++ that it's not just a matter of learning these
five tricks here it's a matter of being a guru basically in the language if you make any mistakes it's unsafe and you could fail you could seg fault and what rust is trying to do fundamentally at a high level is to give you the safety of a language
like Ruby without forcing everything to go through a garbage collector or a reference counter so basically giving you the ability to control where your memory is going directly exactly and for people who know it that could mean putting things on the stack
or a variety of other places where you might want to allocate memory you have direct control over that but you don't have to trade off safety and I think from from an ergonomics perspective if you are a person that has ever tried to write code that's
more efficient by having more control the biggest source of ergonomic pain the biggest source of productivity is is not just that you lose all these high-level features it's also that at any point you could crash so just eliminating the ability to ever
crash really is a big shift in the landscape of of what's possible so what is this enable what does it mean so like I said before I think the way you should always look at the programming landscape is looking for shifts for changes in what some language
is doing what's possible what does it mean to have a language that is both low level and direct memory controlled but also safe what is that enable for us and what it enables is a whole new generation of people who are systems programmers and by that I
mean you everyone in this room it enables every people who maybe would have been excited or interested in low level systems programming to do it and no js' which claims to be low low to the metal that's not what I mean when I say systems programming
I don't mean you know programming on the metal in node.js I mean really really programming on the metal really programming at the level of the machine so before I continue I want to just throw out some real talk here and that's to say that all of us
in this room including myself have been part of the high level language tribe we spend a lot of time talking to ourselves and each other about why we find ourselves being productive in high-level languages and a big part of the high-level language a big part
[ ... ]
Nota: se han omitido las otras 4.096 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.