How Rust Views Tradeoffs

hi everybody I'm Steve and this is a talk called how rust views trade-offs I am on the rust core team I'm currently in between jobs I used to work at Mozilla on rust but a recently left and I don't know exactly what I'm doing yet we'll see what happens but I'm still gonna be heavily involved in rust development even though it's not my day job anymore yeah so anyway uh cool all right I guess I got to click so this is a little overview of what I'm gonna be talking about today this is the like choose the right language for the job track and so I wanted to talk about like how rust views trade-offs and the way that they like what would make you choose rust or not and also just some ideas when you think about trade-offs so we're gonna start off by talking about what even is a trade off in the first place and then we're gonna talk about rusts bending the curve philosophy and I will it's how rust approaches thinking about trade-offs so we go talk about that first and then we're gonna go into a small digression about how things get designed in the first place and this concept of values and then lastly we're gonna go over these four different sort of case studies in areas where rust has had to choose some sort of trade-off and why we picked the thing that we did and the thing that we didn't do and all that kind of stuff so yeah alright briefly before I get into the rest of the talk I want to thank Brian Cantrell a large part of this talk is sort of based on a framework that he came up with there's this talk called platform as a reflection of values from node summit 2017 and it's kind about the story of giant and node and I ojs and all that stuff and he's the one that really got me thinking about a lot of the stuff that ends up being in this talk so I wanted to make sure to give him credit so you should you should watch this talk it's good ok so before we talk about trade-offs it's important that we all agree like what a trade-off actually is I am like a amateur philosophy enthusiast and one of the hardest problems when communicating with others is making sure that you're not talking past each other you have to kind of you have to agree what words mean by using words which is like complicated so so we're gonna get into what trade-offs are before we talk about the specific trade in rust so everyone always does this and it's kind of boring and dumb and I'm apologize but the dictionary defines trade off this is a little more interesting I swear a balance achieved by two desirable but incompatible features or a compromise now the first thing is interesting I think is the sentence a trade-off between objectivity and relevance that's kind of like an interesting example of a trade-off like you can be objective or relevant so like you have to be subjective to apply to reality like I might agree that I'm a little more but the reason I decided to put this on the slide is not because like you know the dictionary says it's such a dumb meme but the thing right below this on the webpage if you google this and I thought this is really interesting is this use over time graph and I was like wait a minute just after 1950 is the first time we thought of the concept of trade-offs so I went into like a deep rabbit hole you know you're supposed to be working on slides instead of working on your slides you're like I need to look up the Linguistics about the word trade-off and it turns out the reason cool the reason that graph that was there looked like that when you could see it is because obviously the concept of a trade-off did not start in the early 1960s but it used to be the the words trade space off and we only started putting them together into one word around the 1960s and so that's why this graph looks like this obviously people use the words trade off and talked about discussions earlier but I just that was kind of interesting so that's why the the dictionary thing is still up there language changes over time and it is cool all right so I got a bachelor's in computer science and one of the things that sort of beat into you in at least in the States is that like there's trade-offs and you have to deal with them and so here are three examples of like classic trade-offs in computer science or programming that you might have dealt with before so one of the biggest ones is space versus time if you like Google computer science trade-off like everyone's like the space time trade-off it's like the vast majority of things on the web apparently and the basic idea is that you can either make something fast or you can make it small and these two things are sort of like independent of each other and so that's like a common situation when you're designing data structures talk about the network all these kind of things a second one is throughput versus latency and so these are two different measures of network activity you know throughput is like how much stuff can you do in a given space of time and latency is like how long does it take you to do the thing and so these are like two things that are often you can get good at one or not the other and then finally a big classic one dynamic types versus static types I wrote Ruby or Haskell because I was trying to think of the most trolli way to describe this description ever I actually have a ruby tattooed on my body I used to do Ruby before rust it was a very dynamic typing enthusiast when I friends Sean Griffin so like I've been going around for last couple years being like I have a ruby tattooed on my body that's how much I love Ruby my friend Sean had his firstborn daughter and he named her Ruby so he like won up to me you like you think he'd get a tattoo and you're gonna be like the biggest thing but I was like fine Sean you win anyway yeah so dynamic versus static typing you know and trade offs so these these trade offs are are great and complicated and their core aspect of our discipline and they're also core to another aspect of our discipline which is arguing on the internet people argue over which one of these trade offs is the right thing to choose and like in some ways that's like kind of dumb but also I think the trade offs are sort of the core of what we do if we think about programming is an engineering task like fundamentally you have to make choices between things sometimes and so that's that's important so rust has this interesting approach to trade-offs that we call bending the curve and this is like sort of an attitude that got instilled in in the rust developers sort of fairly early on I'm not really sure who started trying to think about things this way but it's a way that we like approach the problem of like you have these two things what should you pick and so let's talk about that a little bit so when I was making these slides I felt very clever because I looked at these three trade-offs and I was like wait a minute one of these trade-offs is actually different than the other two I don't know if you have any ideas about which one might be the the different one here but I think I've made a slide since I don't have my laptop it's like totally blank so we're gonna have a little bit of like fun did I guess my next slide correctly yeah through versus latency so like this is often a function of like physics but that doesn't necessarily mean it's always a trade-off right like you can sometimes have systems that are have more throughput and less latency than a different system it's not always inherently a trade off at some point you know physics and wires and stuff I don't fully understand comes into play but like this is an interesting entry point into this idea that like these things don't always have to be at odds with one another even when there's a trade-off and things are usually at odds and if we think about the other ones this also becomes kind of true and so like again these dictionary definitions I'm sorry bear with me briefly this is what Wikipedia has to say so that the dictionary I'll quote Wikipedia a situational decision that involves diminishing or losing one quality or whatever in return for gains and some other aspects basically one thing goes down and another thing goes up now if you think about this a little more generally this is sort of weird with these things I presented to you as trade offs like a lot of time something that smaller is actually faster if you do like high-performance computing and you can fit your computation into your like l1 cache it becomes massively faster and so the like what normally might be a space versus time like trade-off so like a common thing and like compiled languages is like do you inline a function or not and the argument there is like if you in line the function everywhere your binary gets larger so that's like a large issue but you get faster whereas if you do dynamic dispatch instead you know your binary is smaller because you only have one copy of the code of that function but you end up being a little bit slower because you have to actually do the dispatch but in other situations like this idea with the cache these two things aren't at odds and in fact smaller is often faster this is also true for example if you've ever had to download jillian's of gigabytes of JavaScript to load a web page right you're like man if this JavaScript was smaller my page would load faster and a lot of stuff around the web is about making things smaller so they can be faster so sometimes this is not actually like a true dichotomy dynamic versus static typing the non trolli resolution to this is a gradual typing right so you can have things where you start off a little statically and you like move more dynamic or vice-versa there's also is anyone ever heard people describe dynamic languages as unit typed languages before cool you don't know any like functional programming control enthusiasts then great you have your better friends than I do there's an argument that like all languages are statically typed because tights are only a compile-time construct and languages that are damned Italy typed only have one type and everything is one type so haha you still have static types but that's totally useless and only good for making other people mad it's a gradual typing gradual typing is a better example of how like static versus dynamic is a real dichotomy and in fact even in most languages that you know give you static types there's some sort of facility for dynamic types and we're seeing an increase in dynamic languages like Python is introducing this thing called mypie which i think is in the language now that lets you like annotate functions that you want to be annotated with types with types and your stuff gets faster and I like goodness so it's not exactly a pure dichotomy trade-off and then finally as I sort already mentioned throughput versus latency like you can sometimes do better on both that doesn't always mean you can but these are like actually different measurements like throughput is about amount over time and latency is about the distance to like an individual thing so there it's kind of weird to even argue that they're against each other because they're just fundamentally not measuring the same thing so with this idea that like trade-offs don't have to purely be one thing goes up or goes down like if you have two options like this that you see my amazing presentation drawing skills here get ready uh you know you really think that we can choose something that's like here or something that's like there and you have to pick one of the other but in reality this is more of a gradient and so you could like you could choose this instead right so it's like a little bit closer to one than the other but like bending the curve I couldn't figure out how to draw a curve in Google slides is the first presentation of using Google slides so bending the curve is about the idea of like what if you could pick this instead and so this is the best I could do with a curve I'm sorry uh I used to write all my slides in HTML and CSS and stuff but I'm really bad at CSS so I don't know why I kept doing that to myself and then PDF export is terrible and this conference loves PDFs for your slides so like I just did Google slides and it's fine whatever but like the idea of is like grab it in the middle and draw it up towards a different thing like we can we can do other stuff with trade-offs than just look at like two different options and so we can get like unique solutions by thinking out of the box a little bit I hope that was an enterprising enough sentence for you all and so like the way that we often think about trade-offs as I mentioned earlier one thing increases another thing decreases right this is more commonly known as a zero-sum game if you do any game theory or economic theory apparently cordilla but no so like a zero-sum game basically means that like when you add up everyone's scores they end up being zero right so like if you need to lose then I need to win and vice-versa well of course I'm gonna be the one winning right it's the idea and so like but this this this problem is that when you think of this way you start believing that other people inherently have to lose for you to win and it turns out that like not very many things other than economic theory and game theory which are theories like is this actually true in most situations including programming language design you can design things in a different way and that is like a win-win game and so this is a game in which everyone wins or everyone loses we like to focus on the everyone wins part and so it's not really inherently about like you must lose so that I must win is about trying to figure out is there a way that we can both win and so like a win-win strategy means that you can like you know try to figure out how that goes is this idea of bending the curve is fundamentally about when we look at trade-offs we try to figure out a way that we can have both things at the same time and so this bend in the curve really boils down to yeah I like is this trade-off fundamental sometimes it's absolutely true like you there is situations in which someone has to lose for the other person to win but a lot of times we get too obsessed with that idea and we apply it where doesn't have to work and so can we like be a little creative and instead you know have everyone win and this works way more often than you might think all right so before we get into the case studies about west rush what rust actually did so if we like if we think about okay this is the approach we're gonna try to find like win-win solutions instead of you need to lose and I need to win we need to talk about the game that we rack playing and in order to talk about that we have to think about like the concept of design in like an abstract like what is the task when I'm the person in charge of designing a language or designing a system like what is the thing I'm even trying to do like what is that activity if you know any like architects you may ask yourself what is their job really so so this is the part that largely relies on Bryan's work and so fundamental design is about values and so when you're like thinking about a system and you're thinking about building it you need to understand what is valuable to you and beyond that you really need to think about it a little more complicated than just like what do I care about you need to think about like what are your core values that is what is this stuff you absolutely are totally not willing to give up on like is there a hill that you will definitely die on and you're gonna die for sure and so like you know what is that stuff but then also like secondary values there are some things that you know would be nice to have but like if you don't get them it'll be okay and this is often you know a little more complicated because a lot of people like to think that you know you can never compromise on anything and I definitely am that kind of person sometimes but like a lot of the a lot of the creative process actually sticks into this like when you're willing to give a little what do you get back from it and so having more secondary values like you would think that having a lot of core values is very useful but it turns out those are those are useful in some situations but they're not as useful as something you're actually willing to trade off for something else right so having a lot of secondary values is also pretty good and so like what stuff do you want to have but you don't necessarily need to have and then finally what stuff do you just not care about whatsoever and identifying this is really important too because it means that if there's something that you do really want and you have a thing you're willing to give away it's really easy to get that thing if you can figure out how to do that particular trade-off right and so being explicit about the things that you don't care about can be just as important as it's caring about the things you actually do care about so let's talk about rusts core values when it comes to designing things and now I will say that I am on the language design team anymore it's complicated again in the history a little bit later and so this is kind of like what I see so please take this as my personal interpretation obviously rust is designed by a lot of people well maybe not obviously but we'll talk about that later rust is designed by a lot of people and so I'm not saying that they necessarily 100% agree with me that's another funny part about designs you could argue about things Lots people so when I look at rust core values I sort of see these three things as being what rust cares about a lot and I mentioned that they're in a particular order because the funny thing about core values is you sort of also need to decide like if these things come into conflict with each other will actually pick and so the thing rust cares about above all else is memory safety and there's historic reasons for this largely because rust sort of whole idea is like what if we could make a C++ that's actually memory safe and so if you were to give up memory safety you'd be like what are we what are we doing here like this is kind of you know like the whole point of the enterprise is wrong and so rust also really cares about speed but rust cares about safety more than speed so if there's a situation and this is also why I said they're in order right like some historically speaking these two things are kind of at odds and so if there's a situation in which in order to be safe rust has to give up a little bit of safety rust will do it but will try a speed sorry thank you if there's a situation in which we need things to be safe but we have to give up a little bit of speed we will do it but because speed is still a core value we will try our damndest to make sure that we can find some other way to make that happen but every once in a while there's a situation where that's not actually the case and then finally I put proactivity here which is a little bit of like a sort of I don't see like weasel word exactly it's like a little hard to define what proactivity means but rust cares a lot about being a language that is useful to people and so you'll sort of see this expressed differently and the things rust doesn't care about later but basically like rust wants to make decisions that will make it be a thing that you want to use rusts a sentence is terrible I'm sorry but like programmers need to use a language and rust is the language that wants to be used and there are some languages that don't want you to use them surprisingly enough we'll get we'll get into that and that's totally fine like again it's not a judgement about values it's about your judgement of your values so so these are the core things the rest really cares about rust secondary values and these are the things that we would like to have but we're willing to give up a lot of the times are ergonomically and speed rust has some stuff that makes a little harder to use getting ahead of myself but like we'll give up those that ease of use sometimes to achieve those other goals but we still would really like it to be as easy to use as possible another one and this is unfortunate if you've ever used rust I'm sure you're not surprised by compile times being a secondary value the rusts compiler is slow it's a problem we are working on it but like we care more about the final speed of binaries than we do about making the compiler fast like we will always make your program faster if it makes your compile time slower and that's just what it is that said a large part after this talk I'm about to post the like proposal for this year's rust roadmap and one of the major features of it is like how are we gonna make the compiler faster so like we do care about this and we want to get it done but uh you know we give it up maybe a little more than we should even sometimes and then this is kinda interesting correctness is a secondary value and what I mean by this this is rust really cares that your programs are right but like we're not willing to go like full dependent types proof assistant make sure that your code is right like it should be right but like we're not gonna make you prove that it's right and so that's why it's a secondary value is because like we're willing to give up a little bit of correctness sometimes in order for for example organ ama clike proof assistants are really hard to use and I don't expect that many of you in this room have even used one let alone are comfortable using one and so you have to give up a little bit of those kind of correctness tools in order to achieve Organon extend like productivity okay things that rust does not care about I think this first one might be a surprise to a lot of you but it's actually in the name so blazing a new trail and programming language theory the name rust evokes a lot of different things and actually there's no one reason why rust is named rust the guy who made it originally graden used to just come up with new things of why wouldn't whenever someone asked him so there's like six different many reasons out there but one of them is is that like rusts programming language theory technology is like 2002-2006 era programming language terminology it just happens that most languages we used today were made in like 1995 and so rust seems like it's this like really big conceptual leap forward but if you talk to like somebody who is trying to get their PhD in PLT they're gonna be like rust is like real boring like a lot of the text that rust is built on is actually pretty old and so rust is not trying to be a research language we're not trying to push programming language theory forward completely some of the people in language team might disagree with me a little bit they have PhDs it's cool we do do some new stuff but it's like not a thing we're like trying to do as a goal secondarily worse is better rust like is not interested in just sort of throwing something out there and hoping it's good enough and iterating we spend a lot of time trying to get things right and so on the sort of like you know Jersey versus MIT like side of things we are more on the MIT side of things rust will spend a lot of time iterating on features until they are good and we are sort of not willing to just kind of like throw stuff out there and the way you can see this is in our standard library rust is a very small standard library and that's because we're not totally sure that we have great libraries for things yet and so we're not just gonna throw like an XML parser in the standard library unless we think we've got a great XML parsing library because the standard library is where libraries go to die and that's no fun for anyone and so we we tend towards the correctness side than just sort of the throw something out there kind of side of things and then a last one which is kind of interesting for systems languages supporting certain kinds of old hardware an example of this specifically is two's complement versus one's complement integers if you're seeing C++ programmer you may know I hope you know that the representation of integers is undefined and that leads to all sorts of fun shenanigans and that's because C and C++ were developed in an era where a lot of hardware had different implementations of integers and so you're allowed to pick ones complement two's complement or assign magnitude for integers we basically said listen literally all the hardware that gets made today uses two's complement atures so we're just gonna assume you have two's complement integers and you can use a different language if you are programming the machine from the 70s and this is this hardware support like is so true there's actually a paper right now the feature freeze for C++ 2020 just passed but like the next iteration of C++ 23 might also like declare that it only supports two's complement Hardware because it turns out that like it's been a long time since anyone's made ones comment machines except for like one company and everyone's like come on like so anyway we're like willing to ask you hardware support for certain kinds of old things in a name of like we don't have those kind of integer undefined behaviors because we're willing to just say it's two's complement like and that's fine and so that's a trade-off that we are willing to make so there's some some examples of our values oh no now I don't know how to go back let's see there we go cool all right so um a little bit more about values and design an interesting thing is that uh you know it's not just you that has values in the system you're trying to build it's also your users like they have a certain set of values or the things they're trying to accomplish and so as a programmer I think it behooves us to like think about not just the values that we hold but the values of the people that use our software hold and that comes with like you know as a programmer you should use tools that align with your values I really like programming languages and learning new ones but there are some that I have seen where I'm like you know what this language is not for me so I'm just not gonna use it and I'm not gonna denigrate any languages by naming them but like it's it's true that I would be unhappy if I had to program in some languages and that's because they value different things than I value and that's that's totally chill there are other people who have different values than me they can use those languages they are super happy that's literally why we have different languages like it's fine but like I've had frustrations with tools where I was forced to use something and I was like man this tool sucks and then I realized it wasn't that the tool sucked it's that it cared about different things than I cared about and that like weirdly made me more okay with using the tool because I was able to just be like I understand why this friction is happening and I made that job easier and in general those kind of mismatches can cause those problems and I find that a lot of programmers arguing on the Internet about whether something is great or terrible or awesome or horrible really come down to that person has a certain set of values for the things they create and they're talking about a thing that cares about completely different things and that's where a lot of arguments happen so for more than that watch Brian stock it's great okay so uh when should use rust before we talk about the specific trade-offs I figured I would put some examples of like when rust might make sense to you if you find these values to be true in the software you write you may want to use rusts if not don't it's cool there are lots of great languages so I think that rust is ideal whenever you need something that's both reliable and performance yes performance is a word I don't care what you say language changes over time deal with it I've had a lot of bad arguments on the internet I'm really sorry it's really shaped my worldview in many ways there are people who care if you use the word performant they will get mad at you and I'm expecting tweets about it later so performance is important reliability is important when you need those two things you might want to look to rust it's interesting because a lot of people like well when wouldn't I care about reliability and performance and like let's be serious think about some systems you built there's been a lot of them that have not been reliable or performant right like if this there's times in which you are willing to trade away those things and that's totally cool the a lot of the sort of like rewrite it in rust meme comes from places that have built something in a system that is not necessarily reliable performance and then got to scale and realize like oh my god we need reliability and performance and they rewrote a portion of it in rust and we're happy and that's like a really great strategy for managing these kinds of trade-offs I'll talk a little more about that later sometimes you need these things sometimes you don't need these things and that's cool and yeah as I mentioned with the rewrite stuff like sometimes you don't need this things immediately so we'll be here like it's cool go write stuff in other things all right so let's talk about some case studies the first couple of case studies are gonna sort of be about the design of rust itself and trade-offs in the design and the way we approach the design process and then I'll sort of get more specific we'll talk about threading models at the ends this is gonna go in from like broad to concrete so BDF ELLs versus design by committee this trade-off involves who is building your system and who gets to make the calls like who's the decider one model is the BD FL model which is the benevolent dictator for life they rule over their project with hopefully a velvet fist not an iron fist hope that's not mixing too many metaphors they need to be benevolent or else you've got a dictator and that's bad but if their benevolent dictator it's probably good and a lot of people like this model and a lot of programming languages designed this way the other option is designed by committee where a bunch of people who are not invested in the system make the decisions and there's this quote I forgot about this when I was looking at these slides a camel is a horse designed by committee I don't think it's really fair to camels I also have a pearl camel tattoo but like you know there's sort of this like when you look up the definition for this but like it's a pejorative term for and so you know like a lot of people think like oh if something's designed by multiple people then that has also as chances to really go awry right and so we have these two trade offs we let one person make all the decisions and if they make a bad decision we're totally screwed or make a lot of people make decisions and when they make bad decisions we're totally screwed but like which one is actually better and so can we do things differently and so West didn't ever really truly have a be DFL but we went from one person makes decisions to lots of people making decisions over time as the project developed so originally rust was a side project by graden and so he got to decide everything because he was the only person working on it like that's just what happens right you start a project you're in charge like who but he was always extremely forward that he did was not the BD FL which a lot of people were like that's a great sign in a BD FL and and so so eventually he kind of like gave up his power to a bunch of other people at which even more people wanted him to be to be it I fell because I love you're willing to give it up now like you're gonna be great and he was like this whole thing makes me uncomfortable no so we developed the the rust core team and so that became a small group of people whose decision is it was to make decisions about the language but eventually we ran into issues of scale I believe it's my next slide and so we transitioned from having a group of people to having a group of groups of people so now the rust project has our core team which I'm a member of we also have what used to be called sub teams and are now just called teams but like so for example I'm a member of the documentation team as well as the core team so I'm on both there are some people who are on only one team and the idea is that all of the teams are actually equally in charge rust core team is like more of a tiebreaking organization at this point than it is a like hierarchical thing but that's also complicated weird I'm getting to it we don't really vote so we're gonna have ties to break but like it's fine the important part is like rust used to have one person in charge and it had like six people in charge and now it has about a hundred people in charge and so we've changed a lot as this works out and the reason this happened is basically due to scale as the project grew we ran into limits so I was on the core team whenever it was the only team and the problem was is that it was our job so you decide on things and so every week we'd have a meeting and we decide on all the things we do decide on and by that I mean there'd be this big giant list we get through some of them and the next week there'd be even more added on to the list and so it just started to grow and people became frustrated that the core team was becoming his bottleneck and members of the core team were frustrated because like not every one of those decisions was relevant to every member of the team and so if you wanted to talk about like variance in our type system I like read reddit while those meetings happens like I wasn't paying attention but I still had to vote because I was on the team so like that's weird and dumb and then when I was like I really want to talk about whether we choose British or American English for our documentation standards like that was my jamm the people that the phd's in type theory were like yeah whatever Steve says that's fine and so and it took so long to get through all these decisions that like people would be like I've been waiting on a month for you all to make a decision on my pull request like what's going on it would be like sorry we can all let's to decide so in order to scale we decided to sort of like make more than just the core team and so you know that was this like creative solution to this problem and you know that's been helpful but then that comes with new problem with zone because you know now when you have like a hundred people and like 15 teams they all have to like coordinate and so recently I would like to announce that we're about to make our governance team which is basically like a teams team so its job is to figure out where coordination issues are between the teams and helping their team stuff work so it's kind of like a team making team programmers love recursion and so this also means that like you know originally like one of the problems with be DFL versus design by committee that people bring up he's like the B DFL has a grand vision that he toils over like an artist's or whatever and design by committee has like no taste and so one of the problems is you move to multiple people you you lose this cohesion unless you're explicit about these design values right so we all have to like agree like what are the principles that we use to make these decisions and so that's something that we've been getting a little bit better at is communicating to each other like how we make these decisions and why and you know dealing with those problems but so I don't want to say that aventure people run your language is a panacea because it is not but it definitely has helped with the bottleneck of like having documentation people decide on language features okay a second one stability without stagnation so i checked i me real quick all right so stability I had an argument the internet with somebody about what stability met recently they're like you added a new API this release so it's not stable stable means unchanging and I'm like oh god so stability means things don't change but like if you never change then you're also not growing a growth requires some amount of change and so how do you like make sure that you're stable enough that your users aren't dealing with like we changed everything so now your code doesn't compile like enjoy the new feature versus like you know sorry we can't fix that bug because it's relied on in production by this large company and so this is like a trade-off you have to deal with and so we want to be able to have change we also don't want it to affect people that don't want it like opt in change and so we don't actually think that these two things are inherently at odds and so there's this blog post called celebrity stability is deliverable and I have a couple citations from it but if you want to look it up it's on the rust blog there's the URL I'm sure you'll type out that URL in the two seconds it takes me to describe this but you guys google for this on the rest blog and it's like a thing but this sort of lays out our plan and our approach to stability and I'm not gonna get too deep into the weeds but basically we don't want to mean that rust will stop evolving but we want to release new versions of rust frequently and regularly and in order for people to be able to upgrade to those new versions it has to be painless to do so so our responsibility is to make sure that you never dread upgrading rust and if your code compiles on 1.0 it should compile on rust 1 point X without problems and so this is sort of like continuous integration so all the rhetoric around like continuous integration continuous deployment is like if you deploy twice a year and you fear deploy week if you start deploying every week you get better at it right you get better at what you do so if you deploy often you will be better at deploying so let's do that so we can't approach this with the language if we release the language often then we will do a better job of making sure that we don't break stuff because it's not like once a year that we check in with our users if we'd broken all their stuff and so this is kind of thing we do and so we actually copied browsers this basically just says like we land stuff on master we have feature flags and then every six weeks master becomes promoted to beta the previous beta becomes stable if you've ever used Chrome or Firefox you have probably seen this model like every six weeks your browser's like hey new version of the browser came out we did the same thing with rust and that lets us like do these releases but things don't get off of nightly Vic they don't get into a release until they're explicitly marked as stable and what that lets us do is unless this experiment with new features on nightly and actually ship the code and like put it into the the compiler but that won't affect stable users because you're not allowed use Knightly features when you're unstable and so this lets you as a user of rust if you want to be involved and try out new features and get goodies while they're still cooking you can do that by downloading a nightly version of the compiler and trying it out and give us feedback and if you don't want to deal with that because that's a pain then you can use stable and never have to worry about that and stable becomes really easy to update and all those kind of things this says what I just said I'm not gonna read slides to you so what's the trade-off here like the thing with bending the curve is when you introduce a third thing into your this or that like you're also probably introducing a fourth thing that's like you're giving up something there too right so I don't want to always say this means you get everything and so this process is a lot of work for us we have a team for that it's called the release team and also the infrastructure team they both deal with this problem so we've got two teams working on this and so we had to put two teams together to work on it like that's a trade-off we also invested a lot in continuous integration because we need to be testing we actually periodically download every open source package and rust and try to compile it with the next version of the compiler to just double check we're not breaking your stuff that's really cool it also means Mozilla's paying a bunch of money for some servers so thank them we developed a lot of bots so Boris is our continuous integration bot it makes sure that everything passes the test suite before it lands this also means that Bors is always the number one of our contributors list because he merges every single pull request I got lots of stories about that that are funny but there's no time so sorry you got to be about that later but bots are awesome and so basically this is one of those like our users versus us trade offs like we're willing to put an effort to make things easier for our users and that is a trade-off that we will almost always take and so it is a trade-off and we pay the price for you okay acceptable levels of complexity there is sort of two different kinds of complexity there is inherent complexity and there's incidental complexity inherent complexity is just like it's actually complicated and incidental complexity is like you made it complicated when you have to make it complicated and so separating out these two things is important because you can't always get inherent go away cuz its inherent like it's defined sort of in the word but incidental complexity is the thing that you can fight because it's about you accidentally making things more complicated than you needed to and so that's like a skill and a thing to like sort of work on and so but what's interesting about this is something can be inherently complex for one design but incidentally complex for another design and so that values list that you picked earlier can often determine if something is inherent or incidentally complex here's what I mean by that Alan Perlis is this guy I don't actually know what he did other than write witty stuff about programming to be honest but he doesn't thing called epigrams and programming and I found several than I think that are interesting to Russ and so it's easier to write an incorrect program than to understand a correct one a programming language is low level when it's programs require attention to the irrelevant that was my favorite and then finally to understand a program you have to become both a machine and the program he wrote these in the late 80s I believe not totally sure but I think these all apply to rust and what I mean by that is that rust does want to help you write Connect software and Russ doesn't want you to write fast software and so in order to do that like we expose a lot more error handling than many languages do because a lot of stuff can go wrong when you're writing programs as it turns out the network can die in the middle of a connection your user can type in something that doesn't make sense like all sorts of errors happen and so we expose those errors many times when other languages just hide them away this happens in a language design level because we have a type called result that returns from fallible operations we don't have exceptions a lot of languages hide a lot of stuff in exceptions which is where you get that like catch e like throw all like you know the kind of things were just like yeah whatever I have no idea what exceptions is throwing so I'm just gonna like catch them all and re throw it again somebody else can deal with it somewhere else that's not great for correctness but it is easy to do and so we've introduced stuff like a question mark operator to help reduce the complexity but it's still always going to be there because we want you to be able to handle errors and that's important and so that's a way in which our design has made something inherently complex languages that care about correctness or able just be like yep throws a bunch of random crap and that's fine and it becomes much easier to use and so they're able to get rid of that stuff and so it's not inherent for them and same thing with one way that rust does safety and speed together like we achieve those two values at the same time is by having a really great static type system because types are checked at compile time so they're free remember I said about long compile times earlier they're not actually free but at runtime they're free so that's cool but if you ever used a really strong static type system you know they're complicated and that means there's a user Russ is a little more complicated for you to use but the benefit of what you get out of that is programs that are really fast and that's cool but that means that we have this sort of like inherent complexity to achieve our goals and these things actually matter if your goals are not to have safety and speed at the same time to only be fast or only be safe then like you don't need these complicated type systems and things become a lot easier for your users and so that's not inherently complex anymore and this is what I said but that's slide all right last case study before I go away green versus system threads this is the most complicated like actual concrete case study I have for you here so there's these two different models of threading there are more of them as well but for the purpose of this talk only these two exist I'm not gonna get into the details that much but basically system threads are provided by your operating system they're an abstraction for running code you say hey OS please run some more code at the same time and it goes cool it doesn't actually run at the same time but that's the whole separate story green threads however are an API that's offered by your runtime and so this is like a programming language is like hey I have this mechanism for running code at the same time and you're like cool I will use that sometimes this is called n2m threading because you have n system threads that are running em green threads and sometimes system threads are called one-to-one threading because one system thread is one operating system thread these terms are also incredibly loose and you can argue about them a lot on the internet if you want to you can argue about a lot of things in internet if you want to okay so some of the trade-offs involving the picking these things are system threads require that you call into the kernel it's a kernel API and they have a generally fixed stack size yes you can this is a slide I'm not putting every last bit of POSIX on here you get a megabyte 8 megabytes by default on x86 64 Linux green threads however because they're run by your program they have no system calls so that's cool no overhead to calling in the kernel and they have a lot smaller stack size for so for example a go routine has currently eight kilobytes of stack it used to be even smaller they found out that was too small they made a little bigger so from these set of trade-offs it looks like you always want green threads like why would you ever use system threads these are just better let's go there's only one slide I got more uh so as I mentioned earlier about the like with the way rust development changed sometimes your values change over time so rust was before 1.0 for 5 whole years and so originally even though rust had the same design goals and like values it expressed them very differently and so originally rust was actually much more similar to Erlang than C++ it's kind a little weird was awesome but weird and so it provided only green threads because that's what Erlang does and as the previous slide showed you obviously we pick green threads in every situation but over time rust got lower and lower level and we were able to commit more to our performance goals by doing shenanigans and so we had to sort of re-evaluate this choice this was such a contentious like change there were people threatening to Forks the language over it actually there's a whole nother story and I'm time for so the argument goes like this you're supposed to be a systems programming language but you don't provide access to the operating systems API what does what does that even mean and we're like yeah that makes sense and then also the downside of green threads because you have these small stacks and they're different stacks if you want to call into see you have to switch to the regular operating system stack and so that has a cost and that performance is like totally at odds with our previous performance to a goal as well right so we tried to bend the curve and we failed what if we had a unified API to let you pick do you get green threads are you get system threads whichever one you want you ready code one way they're just threading models right so you spent up a new thread doesn't need to be a green thread or system thread it's fine so let's do both so we have this Lib native versus Lib green and you pick the one you wanted at your program and people would write libraries that abstracted didn't care about the threading models you just get to do whatever you want everything will be wonderful the problem is that this gave you the downsides of both and the advantages of neither so that was a problem it turns out that our green threads weren't very lightweight they were actually pretty heavy and there's some other things I have some lists here I'm not gonna read all this to you but basically some things only made sense for one model not the other model but both models had to support both things so that was awkward it was a problem with IO because like only some stuff work properly across both things or just implementation issue embedding rust so if you want to write rust on an embedded system you'd have to say I never support the green threading runtime but the whole point is they're supposed to be agnostic like how's that go and then finally like we committed to maintaining both things so like you just had to be good enough to maintain both of them and that's like a really big burden so we eventually decided to kill it and that was bad and so we realized that we were able to commit to some values more than others so the answers were different there are other languages who only give you green threads that is awesome for them they have different values than we do and so you should take time as you're designing a system to to check back in with yourself and say hey if my values change since I originally made this decision because maybe the decision I made was a bad one and I need to reevaluate it and so yeah now we only have system threads in standard library but I think I have said on this yeah so because we're not have run time it means that you can write your own runtime and include it if you want so there is a two different packages one is called rayon and one is called Tokyo and they are both ways of doing sort of green threads for different kinds of workloads don't have time to get into it we can talk about it afterwards if you'd like there's also trade-offs here as well for example now you have to know about rayon and or Tokyo and you have to pick the right one to use that's complicated and then finally what happens if people made like six packages to do this instead of two so there's some downsides but I don't have any more time so with that thank you so much for coming to my talk the three things you should take away from this are trade-offs are kind of an inherent aspect of our domain but if you think outside the box you can sometimes have your cake and eat it too and you should use rust when you really care about something being both robust and fast thank you so much you

Channel: InfoQ

Views: 25,376

Rating: 4.9525223 out of 5

Keywords: rust programming language, software architecture, programming

Id: 2ajos-0OWts

Length: 46min 34sec (2794 seconds)

Published: Mon Jul 22 2019

Reddit Comments

[u/A1oso]

/u/steveklabnik1 Great talk, I really enjoyed watching this! I'd love to hear those funny stories about BORS :D