Rust: A Language for the Next 40 Years - Carol Nichols

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments

I really like that Carol announced the talks about Zig and Go at the end of her own talk.

No need for partisanship, let's present alternatives as objectively as possible, and let viewers make their own choice.

👍︎︎ 92 👤︎︎ u/matthieum 📅︎︎ May 12 2019 🗫︎ replies

Wow this railroad analogy is breath taking. History repeats! People do repeat the same wrong assumptions over and over again – even though they have proven wrong over and over.

👍︎︎ 21 👤︎︎ u/asmx85 📅︎︎ May 12 2019 🗫︎ replies

I like the Bryan Rust jersey, it's a nice touch.

👍︎︎ 21 👤︎︎ u/epic_pork 📅︎︎ May 12 2019 🗫︎ replies

Anybody else loved the cat and baby photo at the end? That was one of the best touches I ever saw in a talk.

👍︎︎ 1 👤︎︎ u/L0uisc 📅︎︎ May 14 2019 🗫︎ replies

You still need things like tests and things like fuzzers

The only two things named are tests and fuzzers. This makes me fell all warm and fuzzy.

👍︎︎ 1 👤︎︎ u/Shnatsel 📅︎︎ May 15 2019 🗫︎ replies

I really do believe Rust is THE language for the next 40 years, even if I don't know anything beyond the basic syntax and principles and haven't written more than like 100 lines. It's just so powerful and so easy (once you understand the borrowing principle).

👍︎︎ 1 👤︎︎ u/brokennthorn 📅︎︎ May 13 2019 🗫︎ replies
Captions
so you are in the talk rust a language for the next forty years my name is Carol nickels or Golding it's short-circuits I will answer two nickels quicker but you can also call me Carol building if you want I'm Carol's ten cents on all the various platforms I have a lot of links in my slides so if you want to be able to follow up on references and check out some more things this short link will take you to a repo where there's link to view the slides on the web and the readme has just the links pulled out as sort of alluded to in the intro I'm the co-author of the rest programming language book which is available for free online and available in print from no starch press I'm also a co-author on a Manning live video series called rusted motion that's in early access right now and thanks to Manning I have three codes for free access to this rest in motion so the favorite my favorite three questions are going to get access to this so please ask wonderful questions on the slide slide Oh question asking platform I am also a co-founder of integer 32 the world's first rust consulting company and I am an organizer of rust belt rust a regional rust conference this year we're going to be in Dayton Ohio on October 18th and 19th and I'm on the rust core team so if you were hoping for an objective unbiased look at rust you're not gonna get that from this talk I clearly have a slant here I love rust so much that my favorite hockey player is two-time Stanley Cup winning champion Brian rust from the Pittsburgh Penguins and yes you may throw tomatoes at me or batteries or whatever it is that you do here in Philadelphia I could take it alright so in this talk today we're gonna talk a little bit about the railroad industry but you weren't expecting that but we are we're gonna talk about C we're gonna talk about rust and we're going to talk about what the software industry can learn from the railroad industry so a little railroad industry history commercial railroads in the United States started being built around 1830 and trains are really great they let you get across this huge country of ours a lot faster than things like stagecoaches and they really took off built lots of lines of Braille all around the country really fast but as the miles of rail and as the train trips grew injuries and deaths also grew it turns out that once you get a big train moving it's kind of hard to get it to stop again and there were lots of collisions there were lots of accidents and one of the most dangerous jobs on the railroads was that of the brake man because the way you used to have to get trains to stop is someone the engineer would blow a certain signal with the whistle that he wanted to stop and then people would have to go off on the top of each car and turn this wheel to put the brakes on and then move to the next car and eventually the train would slowly come to a stop as all the brakes were applied but this wasn't really an exact science so if at best case if this didn't go well you would miss the station you were trying to stop at worst case if you needed to stop in a hurry probably couldn't and you there were collisions and accidents and this job being on top of the train when it was rainy or icy it's pretty dangerous and a lot of brake men would fell to fall off the train and be killed this was a this is the thousands of brakeman died every year this is second only to mining as the most dangerous career in the eighteen hundred's enter George Westinghouse a an amazing Pittsburgher he invented lots of things was part of making electricity viable and and commercially available and in 1869 he invented the first air brake there have been improvements made over the years but essentially his air brake is what trains use today the way air brakes work are that they're controlled by compressed air rather than a physical wheel on top the car there's a control up in front for the engineer to turn the brakes on and off so they don't have to use the whistle to communicate all the cars are connected so that when the engineer turns the brakes on all of the cars start breaking all the same time and a later failsafe was added so that when there isn't pressure to each car through this connection the brakes are on so that this is safe by default you would have to apply the pressure to turn the brakes off and get the car moving so if something if all the Scotch is connected the Train would would come to a stop instead of continuing to go and this system was a lot more complex than the hand brakes and there was some skepticism this was a quote from Vanderbilt who was the guy behind Vanderbilt University eventually but he he couldn't believe that that error was going to be what stops trains but they did a lot of public tests a lot of demonstrations that involved people riding in train cars with like pillows everywhere testing all these sorts of different kinds of brakes and like running into the wall is because when different kinds of brakes didn't work but the air brakes were passing all these public tests and there were a lot safer and a lot better at getting the trains to stop then the hand brakes were railroads are adopted these four passenger trains pretty quickly because consumers demanded it this is an advertisement for a particular train and the this yellow part here says that the Swift operation of these nightly carriers is safeguarded by Westinghouse air brakes so this is something that the market demanded that that they there were people who were scared to ride trains because they couldn't stop but these air brakes gave people the confidence that they could ride the train safely however on freight trains it took a lot longer for these air wrecks to be adopted and there was this person named coffin who was a big advocate for mandating these air brakes be used on all trains and he worked for the Iowa Railroad Commission and when he started he said that the people on the Commission just kind of thought that this was the way it was trains are dangerous and brakeman were going to die so there wasn't really much we could do that this is just how things were but he a coffin got kept getting all these reports about brakeman being killed and was like no this is these are all the same cause we have to do something about this so he did a lot of advocacy there's this there's transcripts of a Senate hearing for the run the Interstate Commerce Committee that I just find riveting I like reading these Senate transcripts from 1890 and they're amazing coffin had a lot to say in favor of mandating air brakes on all trains the industry people were didn't want to be regulated so they had a lot of interesting arguments they they didn't want to pay to add these air brakes to all their trains they thought that brakeman were kind of expendable and cheaper which is terrible they were like the air brakes are still gonna fail sometimes the like it doesn't matter the hand brakes fail the air brakes are also going to fail so why so why should we they simultaneously made two arguments they said we are already innovating without legislation we are testing new things all the time to improve the safety of the Train if you if you regulate that there's some minimum standard we're gonna adopt the thing that'll meet the law and we're gonna stop innovating so that was one argument in like the next breath this guy at so liberating testimony said and what if something better comes along and we've already have all this sunk costs into these air brakes it's like wait a second wait are you saying you're gonna keep innovating are you saying you're gonna stop innovating because now you're saying what we're gonna happen they really just didn't want to be regulated they said they have other means they have to pay for they can't possibly afford these they said you should have regulated this twenty five or thirty years ago all sorts of things my favorite my favorite objection from the president of the Pennsylvania Railroad Company was are you're gonna regulate the trains what's next are you gonna regulate the bridges it's like yes please we want the bridges to be safe too actually so yeah it turns out that the US railroad safety appliance Act passed Congress in 1893 mandated the use of air brakes and standard couplers to connect the trans together in 1900 it was fully enforced and all trains whether a passenger freight had to be using these safety devices and accidents and deaths of both people being run into both people and things being run into by trains and brakeman operating the trains went way down this helped a whole lot it wasn't perfect but it was way better okay that was your railroad history lesson so now we're gonna talk a little bit about C so why might companies choose C uh who-who works at a company who has Z code in production today okay yeah good all right you you might you probably have a variety reasons why you're doing that it's a proven solution that has worked for 40 years it's fast it has very little overhead it's kind of close to the Machine close to the assembly language it uses very little resources there's a C compiler to target just about any sort of platform you might want to run on the language is simple there's not a whole lot of syntax to learn I would argue that it's a little bit deceptively simple because there's a lot of interesting things that C code can do you might have a lot of existing C code or you might want to interface with existing C code that makes it easy means using C would make that easier and C doesn't really change a whole lot and enterprise software the field moves rather slowly and you don't want to have lots of parts changing out from underneath you and having your code become obsolete so but in order to get all these advantages you have to agree to what I see as a huge disadvantage that outweighs all of that is that C has all these memory safety problems it's not memory safe these problems include use after free double free memory leaks buffer over reads and over writes no pointers databases oh my this is just a lot of problems that you have to sign on to when you are shipping C in production and I'm sure those of you who have seen production can tell lots of stories about problems caused by all of these and a lot of people say well it's you just be more careful then we can avoid these problems it's not a matter of being more careful we're in it's the experience in past 40 years has shown we're not capable of being careful enough there is a vulnerability called stage fright in Android and this blog post was illustrating some C code to try and explain what the root cause of stage fright was and - he said you'd have to be more careful than the entirety of the Android security team every C developer shipping code impression has to be more careful than that there was a great presentation and the post about Microsoft did some studying of the problems that they had to do issue security updates for over the last 12 years about 70% of them were due to memory safety problems we're being you'd have to be more careful than the Microsoft security team there have been some efforts to make C safer there are tools like valgrind there's tools like address sanitizer undefined behavior sanitizers I found this tool called IKOS that does abstract interpretation as a static static analysis it's from NASA so you'd have passive has a really rigorous engineering discipline so if that's the kind of investment you want to make you can check out tools like that there are the misra guidelines all of these kind of strike me as things you do after the fact you write the code first and then you try and make it safe which you have to make sure you do those things you can't forever forget you have to build them in the processes you have to allocate time to do that and fix the problems you find it seems like kind of patching it after the fact there are some varieties of C people are creating none of these have really caught on much you're still writing C that has very little abstractions you have to reinvent the wheel all the time you don't have modern tools that go with it and if you're gonna be switching languages anyway I advocate that you look at all your options and of course they're C++ which improves some things by not everything there's still a lot of undefined behavior there's still a lot of pointer problems you can get into multi-threaded programming is still a big problem in C++ so what can we do about this and that brings us to the Russ part so Russ is a language out of Mozilla research it's trying to learn from the mistakes of C and bring in ideas from a bunch of other languages too I see it as moving our industry forward and trying not to repeat the same mistakes over and over again I have five reasons why I think Russ is ready to last as long as C has the first reason is that it fixes these memory safety problems it's it's an improvement upon the status quo it does this through a system of ownership and borrowing and I'm going to show some examples of how this works this is some rest code it's a main function that creates a string on the heap that we can grow and change in size the owner of that memory is this variable X and when that owner goes out of scope that's when the heap memory it gets cleaned up automatically rust kind of inserts a looks at this code I was compiling inserts a statement at compile time that at the end of main that cleans up that memory so we don't have to write free free the memory that X manually but there's also not a garbage collector running at runtime this is all compile-time this is another example in this example we've got the same string in X then we say let y equals 2x and we try to print out X this line here moves ownership of the string from X to Y and this code does not compile because we're trying to use X again after we've moved it into y so we see this data still only has one owner after that point we've moved it into y Y we'll clean that up and X note is no longer valid and we're no longer allowed to use it after we've moved it so we don't have double three problems and we can't use after free this code instead of moving ownership this borrows Y is a an immutable borrow of X it's allowed to read the the data that X owns but X is still responsible for cleaning up the memory at the end of the function and this code compiles and we're allowed to read using either X or Y in this example we are trying to create a dangling pointer we have an inner scope and we're trying to return a reference to heap data from that inner scope the problem is that the way rust ownership works X is going to get cleaned up at the end of that inner scope so this code doesn't compile because we're trying to use the reference after that data has been cleaned up and rust can see that at compile time and doesn't let us run this code because X gets cleaned up rust has a lot of other safety mechanisms that I don't have time to get into fully one of the rules about references is that you can have either one mutable changeable reference at a time or you can have many immutable references for reading at one time so this prevents databases so that you can't change a value while someone else is trying to read it there are no no pointers there's the option type that represents either something and holds a value or there's none the none value and the compiler makes sure you handle both some or none at compile time out of balance array axises or data structure accesses at run time it just stops the program immediately and doesn't let you continue with invalid data that isn't part of your data structure the ownership rules apply across multiple threads there's parts of the type system that allow you to express transferring ownership or borrowing across multiple threads so now programming parallel or concurrent programs is is checked at compile time that you don't have data races across threads Jessica this morning said a neat word that I hadn't heard before which is the person bite it's what you can keep in your head all at one time and trying to keep all these rules and keep make sure you're doing all these things right in your head with C is really tedious and as we've seen is error-prone it's it's too much for one person to hold your head in addition to your problem domain is and but there's someone who's really good at keeping track of tedious things and making sure that they're right every single time it's our computers so I see rust as making the computer take care of all that tedious tracking of whether the memory accesses are right or not and I can forget about that the compilers gonna tell me when I get it wrong and I have to go fix that yeah but if my comm compiles I I don't have to worry that I that I missed someplace and I can just concentrate on my domain and this is the second reason I think Russ is is going to continue to grow and to last for the next 40 years is that this makes love level assistance programming code something that everyone is capable of doing not people who have extremely large person bite capabilities to hold all this memory access in their head as well as the domain which I'm not sure that anyone actually exists because of the problems we see but more people can program safe systems level code with rust I do have a caveat there is an escape hatch it's the unsafe keyword it lets you opt-out of not all of Russ safety checks it lets you do a few very specific things e and by putting unsafe around some of your code you're saying okay compiler I understand that you can't ensure that this code is going to be safe every single time I as a person I'm going to audit this specific code and I will make sure that I'm following the Murray rules and this is useful in certain performance cases when you're trying to express certain pointer arithmetic when you're trying to call to external code that the compiler can't possibly know anything about so as and as long as you don't put your entire program in an unsafe block what I like about this is that when if you have a seg fault or memory access problem at runtime you know it came from one of those unsafe blocks it's like hey look over here this is probably where the memory problem came from because the compiler didn't check this part so you've you've lessened the places you have to look to debug to figure out those problems I also think that this this unsafe keyword doesn't invalidate things because this is this is opting out of the safety checks rather than opting into them so as opposed to the the sanitizers that you have to remember to run after all the changes to your code this is this is the default is too bright safe code and you can opt out of it if you need to if you want more information on writing unsafe code there's this great talk for building an unsafe foundation the other neat thing is you can build safe abstractions out of unsafe code and there's a whole book on unsafe code called the Resta nomicon like air breaks sometimes don't stop a train rust doesn't prevent all problems you might have a software it does not prevent you from having logic bugs it can't tell that you meant to tell the program to do one thing and it's actually doing another so you stole the need things like tests and you still need to write things like buzzers but by choosing to use rust you're getting memory safety you're not going to have all those problems that C has so let's go back through the reasons that you might choose C and C what we're trading off because there's always trade-offs and in any sort of decision you might make performance Russ is on the order of C's performance there aren't the the additional checks that Russ does are mostly at compile time there isn't a garbage collector it isn't checking much at run time you can still get we have the goal of having zero cost abstractions which means that the abstractions you use our compiled down to code that you could not write better by hand of course there are always things we can improve on but zero cost abstractions are what we're aiming for we're hoping that rust will perform as well as C in the situations you want to use it portability Russ compiles to LVM intermediate representation so you can write rust and compile it for any platform that ll be I'm Ken there are C compilers that target platforms that LVM doesn't there could be a non LOV M back-end for us there isn't one yet there isn't I reason that why there couldn't be other than people putting in the work so if you need to write code for one of the platforms that Russ doesn't support that could be a deal-breaker for you but we do support a lot of platforms so this one is a little bit of both the big downside is rust is more complex and we are trying all the time to lessen the learning curve through books and video courses and and various learning materials there's definitely more features and syntax and C but we're trying to express complex ideas such that the compiler can understand them and that that does take more syntax and more complexity to express if you have legacy code a neat thing is that you can write extern functions that let you call C from rust and rust from C and a lot of languages also have a way to interface with C so you can use that so to say call rust from Python or call Ruby from rust I actually have a whole talk on porting a library the softly compression library that was written C porting it to rust function by function keeping it compiling and passing tests at every commit and the thing I like about this technique is that you don't even have to finish you don't have to convert the whole thing to rest to see benefit you could convert just the parts that change the most the parts that happen most bugs and you could set it aside for a while if you have other high priority things to work on but you still get those benefits along the way of converting little pieces to rust so you don't have to rewrite all of your stuff in rust to see benefits stability is one I want to spend a little more time on there is a new version of rust that comes out every six weeks we have a train really small sort of like Firefox and Chrome do so you might think that Russ is really unstable and it's gonna change all the time but we have really strong backwards compatibility guarantees we've committed to rust 100 came out in May 2015 so we've been stable and shipping stable codes every six weeks since then there is we do have a little bit of an out we've given ourselves we reserve the right to fixing piler bugs patch safety holes and change type in France in ways that occasionally require a new type of annotations we do not expect any of these changes cause headaches when upgrading rust so we can fix our own bugs in practice what this is meant we we run a survey every year in the 2018 survey we had a question that said has upgrading broken your code and ninety two point six percent of people have said no it has not broken your code this question I feel like we need to change the wording of it a little bit because it doesn't really distinguish between breaking compilation which is what our stability guarantees are really about versus breaking runtime behavior or slowing down your code at runtime or speeding it up you don't you broken it in that way and I'd like to I'd like to be able to get into those problems a little bit more and see how we're really doing on our compiled time stability guarantees another part that I think part of our stability story that will let us last for 40 years is that we have a goal of stability without stagnation we want to be able to evolve rust to learn from our own mistakes to make the language easier to use and to learn while still not breaking our backwards compatibility guarantees and the mechanism that rust we've designed to use in rust is called additions and this is a link to a detailed specification of what additions are I'm gonna go over the hi love idea mainly they are opt-in about every three years is what we're thinking we've just made Russ 2018 edition and the original edition of Russ is 2015 so we have two editions right now what they are is it the biggest the biggest change we want to make that's not backwards compatible is adding new keywords for adding new features so for instance we're going to be adding asynchronous functions to Russ the language soon and we wanted the async keyword to be able to do that but your existing code might have function async so if we added that of the keyword your function would no longer be a valid bus function so we added this idea of additions so that if you opt in to treating your code as Russ 28:18 edition code then async would be a keyword but if you did nothing to your code upgraded your compiler it would still treat it as rust 2015 edition code and it would continue to treat async as not a keyword and can you could compile your code when I first heard of this idea I thought it sounded terrible from a compiler maintenance point of view you have to maintain two ways to use every feature forever because we wanted to commit to all editions being supported forever but it's actually not that bad the way editions way the compiler works today is you have your Russ source code the compiler turns it into a high level intermediate representation and then turns it into mid level intermediate representation then turns it into LLVM intermediate representation and LLVM turns it into machine code a lot of the complex analysis that the compiler does such as borrow checking optimizations and code generation happen at this mirror this mid level intermediate representation level the way additions have been implemented is that they're kind of at the surface level they affect the code the source code that you'll write and they affect the high level intermediate representation but once you get to the mid level representation it the mid level stuff is all the same whether it would no matter which Edition you came from so all this complex analysis code can stay the same for both editions and it's only the the first part of this conversion that is an a maintenance burden this because - because the compiler understands both editions and multiple editions once we have more and can compile 2015 code or 2018 code that means we're not going to have an ecosystem split Russ Russ 2015 project can depend on a project written using Russ 2018 idioms and vice versa so it doesn't matter if all your dependencies have opted in or not the same compiler can understand either code and can compile it all together and the important things about this is that you get to pick when you decide to change which Edition you want to use you can keep upgrading your compiler every six weeks but you don't have to switch on that flag to change the idioms until you decide the benefits outweigh the cost of upgrading and never is a totally valid choice we plan to support Russ 28 2015 edition code for as long as rust exists in order to decrease the burden of switching editions we also have a tool call it Russ fix that for as many changes that we can do automatically it will apply those changes and fix up your code and move you to the new edition automatically so we're trying to if you do want to switch to the new edition we're trying to make that as painless as possible also the editions concept I am confident that with using this to evolve the language means we're never going to have rust you oh we're not going to break backwards-compatibility so we hope to be as stable as c is for the next four years we do have a lot of things that aren't done yet with rust that might prevent you from using it in your company we don't have a standard that's going to take a long time and a lot of work we do want to get there someday but it was years and years before C has a standard so we do want to get there but we're not there yet we don't have a certified compiler that will matter in some industries we do want to have a long term support release that gets things like security fixes and certain bug fixes we don't have a policy for that yet cargo is the build tool that rust kind of expects you to use if you you don't use that it gets a little hard to tinker with and some companies have build systems that everything needs to feed into and we have work to do to make cargo fit into build systems that are if you have we have an open-source package registry for open source code we don't have good solutions for libraries that you might want to keep private only share within your company and the ecosystem is still growing so there might not be a library for everything you might want to do in rust yet but these are all things we're working on and we hope to get there soon another reason I think we're going to last is that there are today a number of large enterprise software companies using rusts and they've invested their products in rust so they're invested in rusts future the biggest one of course is Mozilla he heard of the Firefox quantum release a while ago where Firefox got a lot faster one big reason of that was a big component got that was rewritten in rust were shipped with that the component was the CSS rendering that can now render all the CSS properties in your page in parallel and they did some analysis of the security bugs in this component that was written in C++ and found that since the beginning of Firefox there were 69 security bugs in this CSS component if they could have gone back in time than written in rust from the beginning rust would have prevented 51 of those which is about 3/4 of them so I think that's a pretty good improvement on the security and of this Firefox of honey and the speed increase - if you know patio 11 on Twitter Patrick McKenzie he has this word he likes to say a Bama goo book soft and it represents a number of big software companies Apple I don't know of any public uses of rust at Apple they have Swift which actually is really similar to rust I was in the Swift talk earlier and they have a lot of the same problems and a lot of trying to solve the same problems that rust is but use different words for it so I was like sitting there trying to translate him like ah stats oh oh they're hitting the same problem that we are they're really similar and there is cross-pollination there so we're I hope there's more in the future and we can both learn from each other Amazon is the Amma part of this and they recently announced their fire cracker micro VM Google is also kind of secretive they have this fuchsia operating system project that they haven't really said what it's for yet but the code for it is like on the internet and you know open source and there's parts that in rust facebook has the Mononoke mercurial server to manage their huge mercurial mono repo that the canonical implementation of mercurial couldn't handle it fast enough and Microsoft announced they have this IOT edge platform that does analytics like on IOT devices and then sends the results to server so that's a Pam a GU box off we've got four out of five of those using rest publicly the fifth reason that I think we're set up to last is our project governance like the trains the adoption of this is not only for the technical reasons there's also political reasons and I think we are we're building a good foundation here we don't have a be DFL a benevolent dictator for life there's not just one person making final decisions on on rust we have a number of teams and working groups made up of multiple people responsible for different parts of language and we have a lot of different people represented on those teams and working groups we have programming language theorists people with PhDs and programming languages we have people using rust for a product for a company we have people using rust for fun we have people who come from the low level languages like C and C++ we have people from high level languages like I come from Ruby and in our surveys Python is consistently the number one language that people come to rust from and if there's people from functional languages like Haskell that bring a lot of the functional influence interests and our big decisions are made in public by AI system of requests for comments proposals that everyone can see and the teams responsible for making the final decision state their reasoning in public on these RFC's so while we might not make a decision on something in the exact way you might want our our hope is that you'll at least understand why we're making those decisions and feel like we have heard your point of view I feel really strongly that as an open-source person that this is important that this isn't driven Rus direction is not driven by a corporate closed entity making decisions in secret that you have no idea why they're doing and we're not going to take it in some surprising direction if we do you'll if we do take it in a different direction you'll know that we're doing it you'll be able to see us do that another big you think part of our governance is that we have a code of conduct and have since the language was open-source and I loved that this has been since the beginning so we don't have to have the argument about whether we should adopt one or not that decision has already been made we have one we are trying to make a professional space for professionals to work on technology and without problems we're not perfect but we are trying you're acknowledging that there are problems that we need to be handling to make rust a welcoming place for everyone so just to sum up these are my five reasons why I think Russ is going to be able to last the next four years and now we're going to talk a little bit more about the railroad industry and how that relates to what we're doing today this the software industry has a reputation for being a little bit arrogant we think we can do things better than other fields have done them there's the time that a software company thought they could do juice better than other people and actually didn't work any better than squeezing juice packet by hand there was the time that lift reinvented the bus and there's the time that there were people stuck in a cave and Elon Musk thought he could do cave rescues better than the people who specialized in that sort of thing so so we think we're better than other industries if you just add a little software we can totally fix these long standing problems that other industries have had were so much better I think I think we have to we have to work to prove it if we if we actually are better we need to show that we're better and we binding regulation to do this but there's a problem is that it's it's pretty easy for everyone to understand that if you can't stop a train people are gonna get hurt people are gonna kill pretty uneasy to understand that being on top of a moving train in any weather is a dangerous thing but it's it's not easy to understand what what memory on safety even is and it's not easy even easy for us to see what the effects of that are so like I'm trying to imagine the the Senate transcripts from reading that in the future from now of software people trying to explain memory on safety to senators and it's terrible it's I don't see this going well so I don't think I don't think government is going to improve the safety of software but I think we can improve ourselves we can be our own improved informed consumers that demand that our dependencies are safer before we incorporate them into our software because we understand our own problems that is the part that we can show that we are better the railroad industry got really started in 1830 Westinghouse invented the air brake in 1869 and then everyone was using it by 1900 so this is about 80 years you know no that's not right 7 years about 40 years to invent a safer thing about 30 years for people to start using it rust became stable in 2015 I'm arguing that that is a better safer sea I don't know how long it's gonna take us to adopt something that's memory safe can we do better than the railroad industry I don't know I want us to be better I'm not sure if we are better I hope that we're better all right that's that's most of my arguments if you're still feeling a little skeptical that's totally fine I'm I'm willing to be wrong I I am willing for us and to not be the solution as long as we do something let's just do something to fix these memory safety problems that keep happening over and over and over again maybe maybe it's not gonna be rushed maybe there's something better than rest maybe it's sake dick go to the next talk I'm pleading fortitude maybe maybe it's go there's a go talk tomorrow or maybe maybe it's all of them maybe it's there's not gonna be one replacement maybe there's different replacements that are better for different situations that's fine I'm totally okay with that you don't have to choose rest I just I just want us to stop making the same mistakes over and over again let's make some new mistakes [Applause] [Music] [Applause] okay again this is the link to my slides and links that I reference i'm carol's ten cents there's a code for everyone to have that will get you 40% off anything I'm Manning calm and that code is right there and I would like to thank my test audience my daughter Vivian and my cat baby they were very patient provide valuable feedback okay let's see what questions we have let me stop mirroring here or start marine weather okay where are my questions okay let's see which ones I like best okay let's do what's with the name rust there's there's multiple stories here the people who started rust enjoyed riding bicycles and bicycles often have to deal with rust the logo our logo is kind of a bicycle gear there's also a fungus called rust that grows on wheat sometimes that is a potential inspiration that has been suggested as why why rust I like to think of it as something something something stable something that has been around a long time a stable strong coating on the outside there's actually this Corten steel the u.s. steel tower in Pittsburgh has built out of it it's steel that is meant to rust on purpose to protect it instead of paint so I like thinking of Corten steel so partha I liked your question if you are still here I have an envelope for you there yeah thank you okay why would you recommend rust Oberg oh I also like this question so anonymous who asked this if you would make your way to the front while I'm answering there are a couple of big differences in rust and go there actually is aiming for slightly different spaces I they I think they get compared a lot because they came out around the same time and they're both aiming to be kind of C++ alternatives go has a garbage collector which might be a deal breaker in your application so if you can't have something at runtime using resources then I would recommend rust if you're trying to interface with Google products I think go is probably going to be a really smooth way to have everything all in the same language for simplicity purposes and like hmm yeah III think you should check them both out and you should make I think one of them is going to resonate with you over the other so I think you should do some intro programming in both of them and and make your own choice so is someone going to fess up to asking that question for a free code no okay all right arguably one of the reasons for choosing C these days is a great IDE support does the rest have solid IV integration we're working on it this is another one of those things that we know we need to do better at we there's this thing called the language server protocol that is trying to standardize the way that languages can talk to II's and tell the IDE things about the code and we have an implementation that does code completion inline errors jump to definition and BS code has had the best maintained plug-in that uses the language server protocol IntelliJ also has a pretty good rust support I'm I so I did Ruby before bus and there and I love the book working effectively with legacy code by Michael feathers and but in that book he talks a lot about leaning on your tools using your ID using automatic refactorings and in Ruby because of all the meta programming and like you didn't take a string and run it as a function and you just you can't use some of those tools because you can't be sure that you caught everywhere that that function is called because it might be called dynamically from something so I had a lot of jealousy for ie tools while I was writing Ruby and I'm looking forward to the days that we have those tools for rust they're not there yet but they're there more possible to make than they are in Ruby so does anyone want to claim that question thank you very much [Music] okay let's see what other question I like um hmm latest question that's very good question oh okay this is this is a good question I mentioned a new async in 2018 magician and the it's async already in the 2015 mission it's actually in neither Edition right now when we created the 2018 magician we just reserved the keyword for async and we wanted to have a sync support done by the time we shipped the Edition but it's it's not it's not done people are working on it right now there's a lot of open discussion on the RFC's about the exact syntax the exact way it's gonna work so if you're interested you can go check that out but it's is not an either and if once it is done it will probably be available in both it's just that the syntax in Rus 2015 isn't is not going to use a key word so it's not going to be as nice as syntax as it will be in Rus 2018 so who asks the async question all right then that is all the codes I have and I think I'm just about out of time so thank you very much for having me [Applause] you
Info
Channel: ChariotSolutions
Views: 267,718
Rating: undefined out of 5
Keywords: rust, phillyete
Id: A3AdN7U24iU
Channel Id: undefined
Length: 55min 7sec (3307 seconds)
Published: Thu May 09 2019
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.