What's unique about Rust?
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 8 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/52173 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
RustLatam 20194 / 8
2
4
6
00:00
Open sourceFacebookParity (mathematics)Software repositoryUniqueness quantificationRepository (publishing)Extension (kinesiology)Projective planeComputer programmingPoint (geometry)Level (video gaming)Different (Kate Ryan album)Structural loadMultiplication signVideo gameComputer animationLecture/Conference
01:11
JukeboxExecution unitOffice suiteNumberRepository (publishing)Row (database)Formal languageSoftware repositoryDifferent (Kate Ryan album)Lecture/ConferenceComputer animation
02:17
Hecke operatorProduct (business)Context awarenessRuby on RailsState of matterMultiplication signRight angleLecture/Conference
03:02
Ruby on RailsPlug-in (computing)Core dumpServer (computing)MereologyFormal languageBuildingLecture/Conference
03:50
Physical systemDrop (liquid)Data storage deviceFacebookGoogolBuildingProduct (business)Right angleNegative numberLecture/Conference
04:30
Game theoryTunisProjective planeNegative numberMultiplication signGoodness of fitBuffer overflowRow (database)Stack (abstract data type)Lecture/ConferenceComputer animation
05:21
Different (Kate Ryan album)Right angleFormal languageBitWordSlide ruleCASE <Informatik>Computer animationLecture/ConferenceMeeting/Interview
06:10
Domain-specific languageSystem programmingComputer programmingMultiplication signFood energyDomain-specific languagePhysical systemComputer programmingSemiconductor memoryBefehlsprozessorSystem programmingLecture/ConferenceComputer animation
06:49
Domain-specific languageSystem programmingComputer programmingPatch (Unix)Read-only memoryAbstractionKernel (computing)Run time (program lifecycle phase)Control flowConvex hullTypsystemQuicksortRight angleMereologyGame controllerType theoryPhysical systemComputer programmingJava appletTerm (mathematics)Key (cryptography)Social classIterationHash functionTable (information)Vector spaceCodeFormal languageRun time (program lifecycle phase)Library (computing)Object (grammar)SpeicherbereinigungInterpreter (computing)BitInheritance (object-oriented programming)Pointer (computer programming)Power (physics)Product (business)Prime idealSoftware bugDoubling the cubeCartesian coordinate systemAbstractionSemiconductor memoryCompilerFreezingLevel (video gaming)Plug-in (computing)Lecture/ConferenceComputer animation
10:02
Inheritance (object-oriented programming)Fluid staticsCompilation albumMultiplication signSpeicherbereinigungComputer programmingRun time (program lifecycle phase)CurveBitRight angleCompilerType theoryPhysical systemProduct (business)CodeGoodness of fitLecture/Conference
10:45
TypsystemCoefficient of determinationRight angleRevision controlExtension (kinesiology)Term (mathematics)Task (computing)Order (biology)Software bugWeb pageProcess (computing)MereologyLecture/Conference
11:41
Parallel portCross-site scriptingType theoryPhysical systemDifferent (Kate Ryan album)Multiplication signRight angleLecture/ConferenceComputer animation
12:20
Physical systemSquare numberFunctional (mathematics)AreaMatching (graph theory)RadiusClique-widthDifferent (Kate Ryan album)SummierbarkeitSet (mathematics)Right angleField (computer science)String (computer science)CodeCASE <Informatik>Category of beingEnumerated typeAlgebraic closureType theoryPhysical systemShape (magazine)CircleFormal languageAreaSquare numberPattern languageMatching (graph theory)TheoryMultiplication signComputer programmingJava appletElectronic mailing listFunctional programmingComputer configurationInheritance (object-oriented programming)Telephone number mappingPointer (computer programming)Generic programmingNormal (geometry)Social classFunctional (mathematics)Lecture/Conference
15:33
Windows RegistryFormal languageType theoryComputer programmingTelephone number mappingProgramming languageCodeDifferent (Kate Ryan album)Physical systemLine (geometry)Arithmetic meanReal numberRight angleData miningCASE <Informatik>BitExtension (kinesiology)Term (mathematics)Repository (publishing)RandomizationRevision controlVideo gameData managementSystem softwareLecture/Conference
17:25
Formal languageFormal languageMereologySource codePoint (geometry)Multiplication signOrder (biology)Pattern languageGame controllerThread (computing)Goodness of fitFunctional (mathematics)Presentation of a groupCrash (computing)CoroutineSoftware testingRight angleLecture/ConferenceComputer animation
20:00
Right angleSlide ruleFunctional programmingPresentation of a groupProgrammer (hardware)Lecture/ConferenceComputer animation
20:45
Video gameRight anglePattern languagePresentation of a groupObject (grammar)Multiplication signLecture/Conference
21:26
Right angleSemiconductor memoryShared memoryMessage passingFormal languageQuicksortLecture/Conference
22:04
1 (number)Multiplication signRight angleFunctional (mathematics)BitType theoryThread (computing)Parameter (computer programming)Point (geometry)Different (Kate Ryan album)Slide ruleGodTotal S.A.Computer animationLecture/Conference
23:48
Interior (topology)Functional (mathematics)Right angleDifferent (Kate Ryan album)Parameter (computer programming)Type theoryError messageComputer programmingSystem programmingWordCompilerCodeLine (geometry)Key (cryptography)CodecCompilation album2 (number)Shared memoryComplete metric spaceParallel computingLecture/ConferenceComputer animation
25:20
Physical systemParallel computingRight angleData structureRule of inferenceOrder (biology)CurveMereologyLecture/Conference
25:57
Pattern languageControl flowNP-hardContrast (vision)Library (computing)MathematicsChemical equationDifferent (Kate Ryan album)Loop (music)AbstractionCompilation albumError messageFormal languageCodePattern languageRight angleLecture/ConferenceComputer animation
27:32
Power (physics)Library (computing)Different (Kate Ryan album)Right angleThread (computing)Dependent and independent variablesProgrammschleifeSoftware bugTwitterMereologyPower (physics)Computer programmingCompilerParallel portLecture/ConferenceComputer animation
28:20
HistologyLibrary (computing)Slide ruleRight angleSerial portSoftware maintenanceStructural loadData structureLine (geometry)CodeMereologyBitComputer animationLecture/Conference
29:20
ProgrammschleifeLevel (video gaming)Software frameworkWeb 2.0Parameter (computer programming)Game theoryBuildingBlock (periodic table)EncryptionCurveSlide ruleParallel portRight anglePrimitive (album)Computer animationLecture/Conference
30:16
Library (computing)Loop (music)BuildingExtreme programmingPrimitive (album)Parallel portQueue (abstract data type)Interactive televisionQuantum stateCodeWeb 2.0Software frameworkLecture/Conference
30:59
Object-relational mappingDatabaseMappingBridging (networking)Level (video gaming)Error messageWritingQuery languageTwitterMotion captureObject-relational mappingDichotomyRight angleSequelLecture/Conference
31:46
Open setParameter (computer programming)State observerWordDifferent (Kate Ryan album)Parameter (computer programming)Formal languageMereologyRight angleArithmetic meanLecture/Conference
33:08
Thread (computing)Commitment schemeAbstractionPerspective (visual)Extension (kinesiology)Library (computing)SpeicherbereinigungFormal languageRun time (program lifecycle phase)Lecture/Conference
34:09
Physical systemRun time (program lifecycle phase)Beta functionOpen sourceThermal conductivityCodeRevision controlDependent and independent variablesElectronic mailing listDifferent (Kate Ryan album)Web 2.0BlogReading (process)Group actionUniform resource locatorCASE <Informatik>Slide ruleMotion captureRight angleMoment (mathematics)Open sourceLecture/Conference
35:58
Identity managementSoftware bugSource codeRight angleDifferent (Kate Ryan album)Java appletWritingSoftware bugCodeSpeech synthesisRoundness (object)BlogTheorySelf-organizationFormal languageType theoryDomain-specific languageCASE <Informatik>Open sourceLecture/Conference
37:34
Execution unitMultiplication signRegular expressionTwin primeFigurate numberLecture/Conference
38:20
Video gameoutputPhysical systemEndliche ModelltheorieAddress spaceCASE <Informatik>Lecture/Conference
38:58
Address spaceCASE <Informatik>Right angleDomain-specific languageLibrary (computing)Stability theoryProduct (business)VideoconferencingStructural loadFormal languageMultiplication signBitPhase transitionPoint (geometry)Different (Kate Ryan album)Core dumpCompilerPhysical systemCausalityLecture/ConferenceComputer animation
41:43
MereologyOpen setBuildingProcess (computing)Physical systemLecture/Conference
42:30
Projective planeMultiplication signBitDifferent (Kate Ryan album)CompilerMereologyState of matterFocus (optics)Disk read-and-write headRight angleLecture/Conference
43:21
CompilerGroup actionLevel (video gaming)Regular expressionSoftware bugIdentity managementSource codeScheduling (computing)Personal digital assistantWebsiteQuicksortVapor barrierProjective planeCompilerBitMultiplication signMereologySelf-organizationGroup actionLink (knot theory)Internet forumGreatest elementRepository (publishing)Point (geometry)Lattice (order)BuildingSet (mathematics)Level (video gaming)Different (Kate Ryan album)Coordinate systemMIDIShared memoryOpen sourceSoftware bugPresentation of a groupRight angleSlide ruleCodeTask (computing)Lecture/ConferenceComputer animation
46:31
Open sourceFacebookParity (mathematics)Lecture/ConferenceComputer animation
Transcript: English(auto-generated)
00:15
So, yeah, I'm going to talk today, so my name is Nicholas Matsakis.
00:20
I'm going to talk today about Rust. I've been working on Rust since 2011, so like seven to eight years. I think that's probably one of the oldest people. And a few things have changed in that time. So when I started, the project was in a repository called Graydon-slash-Rust, because it was still a personal project to some extent of Graydon horror.
00:43
And there was a big warning on it that said, like, don't use this, if you run this program anything could happen, it might eat your laundry. I think that wasn't true, probably that was unlikely, but, you know, that was the point. It was the very early stages. And in my personal life, things were a little different. For example, my daughter was just born.
01:02
You can see now she drew these pictures, you'll see some more of her pictures throughout the talk. So this is a picture of us, kind of, because it's cute. Wait, load. There. That's me and her from the first day or something at Mozilla, that was the old offices, we had a big dinosaur.
01:20
So, yeah, so I've been working on Rust for a while, and, you know, things back then they were a little different. I went looking through the history of the repo. The syntax, for example, was a little different. This is, if you know Rust today, you would recognize this more like that, that's how it looks now. But back then it was written a little differently, and we'll see that there, I'll talk later
01:42
about how the language was different in deeper ways too, not just the syntax. But these days, you know, Rust is in a very different place. So this is a chart showing the number of packages in our package repository. And it starts in 2015, which is about when Rust 1.0 was released, so like three years
02:03
ago. And I think, if I'm not mistaken, you can kind of see, those of you in the front row can kind of see a little bump, maybe that was 1.0, maybe it wasn't, I don't know. Alex tells me no, but that's okay, I'm going to say that it was. And obviously things have changed, right, in the meantime we've grown a lot more and we're
02:21
starting to really accelerate, which is really awesome. And not only that, but we've also started to see a lot of people using Rust in production. You saw our various sponsors here, for example. I think the first production user was Yehuda Katz, who, if you're familiar with Ruby on Rails, or Ruby, you might know him from that context, he also built Bundler.
02:42
And you can see that, you know, way back in 2013, he started using Rust when it was in a very unstable state, so this was like two years before 1.0, we were changing things all the time, and I think our reaction when he said he wanted to put Rust in production was kind of like this, right, it was like, what are you talking about?
03:01
That's a terrible idea, but he did it, and it served a role for them, because they were building something in Ruby, they were building a Ruby on Rails kind of plugin, and they had a problem that it was, most of it was fine, but sometimes what it would do is it would monitor your Ruby on Rails installation and your server, and it would run too slowly, and it would actually, you know,
03:21
not just monitor it, but actually be slowing down and causing problems sometimes, and that wasn't good, so they wanted to rewrite the core performance parts, and they needed another language to do it in, they'd already tried to tune it in Ruby as best they could, and so they ended up choosing Rust, and it worked out really well for them, but I think it also worked out really well for us, because we got Yehuda, as well as a kind of influx of people
03:44
from the communities, like the Ruby community and so on, that brought a lot of new ideas to Rust, and really started to influence it, right, and Yehuda himself ended up building Cargo and a bunch of other things, so it was good for both of us, and since then there have been a lot more production users, these are kind of the biggest names, I would say, the most household names,
04:03
you might've thought that Mozilla would be the first production user, but actually we were pretty late, we kind of just waited and said, I think most, the rest of the company was content to say, okay, you guys just tell us when it's ready, we'll let you mess around, but there are a bunch of companies here that you probably recognize, and if you go to our website or check out the sponsors,
04:20
you'll see a bunch more, so that's pretty exciting, right, and you might think someone who's been working on Rust, I would be like super excited about this, but I'm kind of a cynical negative person at times, I'm also, I don't project that way, but it's true, and I, and I think to myself, well, sure, they're using Rust,
04:41
but do they like it? Like, does it, that would be better, right? They probably just hate it, but they'd know that it's good for them, but actually people seem to kind of like Rust too, right, and for me that's really exciting. In fact, I might even say that they, they love Rust sometimes.
05:02
We won after all the most loved award two years in a row, at Stack Overflow and that's pretty cool, and it kind of got me thinking about, you know, why is that, right? So this definitely makes me happy. This is kind of, all right, not only do they use it, but they actually like it, but, but, but why,
05:22
what is it that people are excited about? And I thought that's what I would try to talk about today to, to kind of put this puzzle together, right? Um, of what, what are the pieces of Rust that combine to make it a kind of different experience, uh, that people are interested in that might make something the most loved language
05:41
or, and so forth. Right. And like I said, I'm a little bit cynical. So when I thought about this, the first thing that word that popped in my mind was it's probably just hype. Probably they like it cause everybody else says they like it. And I realize now that this slide, like this movie is probably kind of old and people don't know what's going on here, but this, he's doing the Macarena in case you can't tell, uh,
06:03
which maybe you've heard of it. I don't know. Anyway. Uh, but I think like, I don't think it's just hype anymore, right? I used to think that and maybe in the beginning I think there was some goodwill and we had a lot of energy, but over time you wouldn't see this much people getting excited, this many companies picking it up if there was really nothing,
06:20
nothing underneath it. So I think it's more than that. And so maybe then it's the domain, maybe it's this like systems programming, right? Which I think a lot of people don't even know, including me actually, very precisely what that is. I like be honest, just gave a definition. He's the person who invented C plus plus that I think is pretty good, which is systems programming is like programming when you are aware of your
06:45
resources, let's say when resources matter, when it matters how much CPU you use, how much memory you use, that sort of thing. And you know, I think at the really, at the end of the day though, people like their programs to go fast, right? That's kind of definitely true. And rust,
07:00
rust tries to deliver on that. And I think that's a big part of our appeal, right? So that's like one of the puzzle pieces and I'm going to label it zero cost abstractions. And that term may not be familiar to you, but the reason I call it that is it comes from C plus plus, right? And it's this idea that C plus plus has a bunch of key aspects of its language design that work together so that when you build classes and you build
07:23
new layers and things like that, like you have iterators and hash tables and vectors, they perform as fast as they would have done. If you'd written the code in a lower level way, if you'd written the code kind of directly in C. So if you use libraries, you don't pay a cost for using those libraries. And that's, that's something that's kind of unique to C plus plus.
07:41
It's not really true in languages like Java or JavaScript where adding more objects, adding objects on top of objects and wrapping other objects with them kind of increases memory usage, increases the amount of work that the compiler has to do. So that's part of it I think. And that it's also the fact that rust doesn't have a runtime, which means there's all these places where you could used to be,
08:02
you could only use C. It was kind of the lingua franca. Like you want to extend your Python interpreter while you can write a C plugin. Right. But now with rust, you can write a rust plugin. So that's really cool. But you might then wonder, okay, so that can't be the whole story because if it were just the performance, we could just use C plus plus. We had it already. Right.
08:22
But C plus plus is kind of like this rocket a little bit. Like it's super powerful and it's cool, but it doesn't always go the way you expect, right? When you actually put it into production. And of course that was like a prime motivator for rust itself, right? We know this at Mozilla from a lot of experience that while C plus plus gives
08:42
you this control and this doesn't have a runtime, it also gives you all these kinds of bugs that are sort of impossible to track, to track down and deal with like double freeze and use after freeze. If you've never dealt with these or don't know what I mean, then consider yourself lucky. Uh, and if you do, you'll know exactly what I'm talking about. Right.
09:02
And the usual solution to all these problems of bringing in a garbage collector isn't quite right because first of all, of course it's sacrificing the control and that sometimes that's fine for a lot of applications. That's fine. But there are a lot, if you want peak performance and so on, it's not so great. And secondly it didn't actually solve all the problems like a GC language,
09:25
Python or Java or something. You still have no pointers. You can still have data races. So you solve some of the problems. You gave up some of your control, but you didn't, you didn't solve all of it. And that's where a rust kind of tries to fill this gap, right? We're trying to have all the control or all the runtime and none of the
09:44
problems. And mostly we succeed, I would say, which is pretty cool. Um, but sometimes I found that, you know, you might think, well, okay, so it sounds great. Why would somebody not use it? I agree. But sometimes type systems can be like a kind of a hard sell.
10:02
I think the way basically the way that we solved all these problems is by not using something like a garbage collector at runtime, but by doing a static check at compilation time. And so we check that your program behaves correctly and you have to learn how to work with the type checker. So there's definitely a learning curve to this approach. It takes longer to get started. You have to learn how to factor your programs differently.
10:21
And that can be a bit tough, right? Uh, it's, if you're trying to ship a product, the last thing you want is your compiler telling you, no, I won't run that code. Right? I mean, or is it actually, because I think that it's correct. Like type systems can feel like the spinach that your parents kind of forced you to eat when you were a kid. You know it's good for you,
10:41
but you don't really want to eat it exactly. And I think they are kind of like spinach, but not that nasty boiled spinach. This dog, I don't know who's feeding their dog spinach, but more like this, like Popeye spinach, right? The kind of spinach that, yeah, it makes you really strong and lets you do stuff that you couldn't do before.
11:01
So let me give you one example from Mozilla where this was true. So we have, you probably can't read that. That's okay. We have a recently shipped in a new version of Firefox and extension that lets us render your, uh, do some of the CSS processing in parallel. So this part that's called selector matching,
11:21
it's part of the process of displaying a webpage, right? And the thing about this problem is that it's, it's so-called embarrassingly parallel, which is actually a technical term. And it means like it's so easy to paralyze. It's really kind of embarrassing if you don't do it because it's just a big bucket of tasks that can be done in virtually any order.
11:40
And yet this bug was only recently closed. And if you look when it was reported, let me make it a little bigger for you. It was reported eight years ago. So somehow over, over eight years of C plus plus people, like really knowledgeable people trying to do this, they didn't succeed even though it was an embarrassingly easy problem to do. Right? And in fact we tried, it's not for one of trying.
12:02
We tried three times, twice in C plus plus and once in rust, right? And only once did we succeed. So that should tell you something about what a difference it can make to have a type system on your side, kind of checking things over for you. Now, but so what is the difference then if we look, okay,
12:21
so we know that the type system is useful. Great. But, but what makes it useful? What makes it more useful than other types of systems say, which can sort of be very controversial and maybe not so helpful. I think a normal type system kind of gives you structs. Maybe you have fields, some, some methods on those structs or maybe classes,
12:41
but you know, it's, it's kind of, it captures a lot of what you're trying to do, but a lot of times you run into situations that it can't describe. And what Russ tries to do is add a lot more patterns to that so that you can describe a lot more things and describe how your program works more precisely. So one big piece of that is something called enums.
13:01
Um, enums are something we borrowed from functional languages, but it's kind of like a struct in that you have a list of fields, but you have multiple variants, right? So you might say, okay, I have a shape and a shape can be either a circle or a square. And if it's a circle, it has a radius. And if it's a square, it has a width and a height. So you have different sets of fields depending on which case you are.
13:23
And then you can do things like match across them. So you say, well, let me look at that shape. If it was a circle, then I'm going to run this code, which is computing the area in this case. And when I'm running that code, I get access to the field radius, but I don't have access to these other fields, width and height that don't apply in this case. Um, and similarly,
13:44
if it were a square, then I can, I get access to width and height, but not the radius. So that's pretty useful. And this, this kind of enums are something we use everywhere in rust, right? And they really help us capture a lot of patterns that would be a lot more verbose. I mean, you could write this in theory with subclasses.
14:02
You could have a base class shape and a subclass circle and a subclass square, but it's just a lot of code spread out over a lot of places compared to this kind of compact, uh, little, little snippet, right? And so you don't wind up using them as much, uh, as you would otherwise. And that makes a big difference. And so one place we use them is to get rid of no pointers, right?
14:23
So a Java string, it might be a string, but it might also be nothing at all, right? Whereas in rust, if you have a string, it's really a string, but if you want to maybe have nothing at all, you can use something like option, which is an enum. It's a generic enum. So it's based over some type T. Uh, in this case it might be string,
14:41
let's say. And it's either yes, it's either some, which means there is something there or none like nothing, right? And that means that the type of your variable actually reflects, could it be no or might it not be no. Uh, is it a, is it a string or an optional string, which in turn means that when you write code that uses that variable,
15:02
you can remember and handle the case where it might be null correctly. So these little things, they kind of add up, right? They make being able to express the pattern you want to express concisely means it's nice to use instead of annoying, right? And there's a lot of things like fall in this category. I think enums,
15:23
closures, uh, I don't know what else traits and generic programming. We have a lot of features that they're not really unique to us. They kind of were borrowed from other languages, maybe tweaked a little along the way, but they let us say things that are hard to say, uh, sometimes and that's really powerful. And I think one of those is kind of outside of the language,
15:41
but it's worth mentioning is just cargo itself, our package repository and package manager, because this is what lets you take some random piece of code and just use it with like one line of code to download, build and configure it. Right. And if you've ever worked in C plus plus, you know that that didn't used to be the case with system software, that it was easy to reuse other things. So that's,
16:02
that's a piece of it. But those things are not unique to rest either, right? There are the things we borrowed from other languages. Uh, I think the last piece of this, of the type system, the kind of most central piece is ownership and borrowing. And this is an extension that really is in a way unique to rest. I mean,
16:20
we borrowed it from research languages that are out there, but in terms of an adapted it, but in terms of, uh, mainstream languages, it's, it's kind of novel, right? And the key aspect of it is unlike say an Enum and Enum is a different version of struct, right? A struct tells you what data is there and what you can do with it.
16:40
And Enum also tells you that, but it has some more flexibility. Maybe it's one of two different kinds of data, but ownership and borrowing let you describe something that's completely orthogonal. Another aspect, not what data is there, but who has access to that data and what permissions do I have? And that lets you expand the scope of things that you can talk about. Yeah. Let me give you some examples,
17:02
but like I want to kind of give a good idea for what it feels like to use ownership. What does ownership mean in a programming language? Um, I think we know what ownership means in real life, right? Kind of this guy, if I own something, it's like, it's mine. And importantly, it is not yours, right?
17:22
It's that's the key bit. And I think if we actually look at most programming languages that are out there, we find that they're pretty good at the mine part and they're not so good at the not yours part. And that's important, right? And actually the source of a lot of problems. So let me, let me walk you through an example. This is using go. I'm not picking on go.
17:43
It could be any language. I find ghost syntax actually quite nice for this. So it's a good example language. Um, but really any garbage collected language has this pattern. So what we're going to walk through is two, two go routines, which are two threads and go right to independent like things of control.
18:01
And the first one, Oh, here's some more of my daughter's pictures, uh, which I love. The first one is going to be running this function foo and you see that the first thing it does is it creates a gift, right? And it puts it in this variable regalo and okay, this is a struct, it has some value. And then what we're going to do is we're going to send it across this channel
18:21
over to another go routine. It's very excited. I'm looking forward to receiving the present. But even though we sent it like logically we gave this gift to the other go routine, but I'm going to draw halfway between them because really we kind of kept some of it for ourselves, right? We still have this variable regalo and we can still use it even though we
18:43
sent this gift to the other party and there may be thinking that it's there is now it's kind of both of ours. So for example, I could go and open this present and find what's inside. Um, and maybe it's a blueberry. I don't know. Uh, so yeah, I asked my daughter, I said, just,
19:00
just draw whatever you want and I'll put it in somehow. So this is what I, this is what I got. Uh, but that's okay. Uh, so, so then we could open it and now that's kind of a problem maybe for the other side because you know, they got their present day and they were expecting that they could open it. They wanted to open the present, but it's already open because we did it. And now we have this, this could,
19:22
this could lead to a crash. This could lead to all kinds of things, you know, or maybe it's just fine. I don't know. But the important point is this is what we call a data race. Basically we now have these two independent actors, these two threads or two go routines. They're both working on the same gift and they're both, they're not coordinating their time with each other. They can open it in any order. So different times that you execute it,
19:43
different things might happen. Sometimes it crashes. My experience is it works really great whenever you're running your tests, right? But it doesn't work so good when someone else is running the test, then it will crash for sure. Uh, and I mean, I should say like in the days when I worked on C plus plus,
20:00
I definitely spent evenings just watching a movie, running the test over and over waiting for it to crash exactly once, even though it would crash consistently for the customers we were working for. Right. It can really be frustrating. Uh, and so next slide. Thank you. So what went wrong here? Kind of what,
20:21
how did we get in this situation that we had this present and we both open it and nobody knew who was supposed to open it? I think the answer is there are kind of two ways we've, we've looked at this problem. There are like two things that went there combined to cause a problem. First we had mutation. So we had this idea that we could open the present and if you're a functional program or you might look at this, this slide before and say,
20:42
well, that's your problem. You shouldn't have been opening the present. You should have been creating, you should have left the close present is just an immutable object for all time that never changes, but it can create an open present from it. And then there's no problem because now we're both expected a close present and that's what we got. And that's true. But that,
21:01
if we don't allow any mutation, we kind of give up on a lot of efficiency, which is what we were trying to do in the first place. And we kind of, uh, it's hard for us to express some things in the most natural way I would say. So mutation is a fact of life presence get opened, and then they are opened. Uh, you can sort of hide it, but then you have to capture this pattern in another way.
21:22
Somehow you have to, you may still need to agree whether or not you opened the present and so on. Right. Um, and so that, that's, that's one side, but you might look at it from the other side of this and say, well, the problem was not the mutation. It was the sharing. You shouldn't have had shared memory. So some like a language like Erlang or something has this really nice approach where whenever you send a message,
21:43
also JavaScript, whenever you send a message between two actors, you just copy it. So you don't share the same gift. You just have two gifts, one on each side, right? And they can both be opened independently. And that's okay too. But that again costs efficiency. And again, it might be something that we wanted to sort of have a unique resource.
22:00
Some things can't be copied, right? Um, so what rust does is take a different approach. We say, okay, we're going to allow sharing and we're going to allow mutation, but we're going to impose with the type checker a requirement that they can't happen at the same time. Right? And as long as you're not, as long as you have only one copy of the gift, you can go ahead and mutated all you like and nobody else can see it.
22:22
So nobody else can be surprised. But if you're going to share the gift across many people so that they have two different threads have access to it, then it has to be immutable so nobody gets surprised. And that turns out to capture a lot of things that we want to do. Right? So if we take that exact example and we run it through and rust, we'll see it turns out differently. Um, this is some rust syntax.
22:42
So we have a function, it's called main and it's gonna, it starts out kind of the same way. We create a gift and then we, we write channel dot send and we're going to send our regalo across the channel, right? And on the other side, this is what a channel type might look like in rust. Okay.
23:02
So it's a little more rust syntax. Um, let me just walk you through a bit of it. We have this keyword, imple that declares methods in rust basically. And this is going to be a generic method, which means a channel and rust would have some type associated with it. Uh, that says kind of, uh, how much,
23:21
what kind of data we're sending. And so on the other point when we take the argument here, when we say that we're taking a value of type T and rust, this is where the difference really lies. What that means is we say that okay. He just showed me a slide saying I only had 10 minutes and I was like, really?
23:41
Oh my God. Uh, no. Anyway, so when we get a channel of, we get a value, sorry, let me reset. When we're in a function and we have an argument in rust and it's of type T, let's say what that means is I want ownership of a value of type T. I need to have it and you can't have it. Right. And that's the key difference.
24:00
So that means that this gift is going to be given from the left hand side to the right hand side. And on the left hand side here, when I pass a value like this, I know I'm giving it away. Um, I'm not just kind of giving, sharing it, I'm actually giving it to the other side completely. So I can draw this gift is moving all the way to the right hand side.
24:21
Right. And then you might wonder, well, what happens? Okay. So I just, I use different words, but the code looks the same. So what happens when I go on and I keep using this local variable even though I gave it away? The answer is the compiler tracks what you gave away and what you didn't give away and you get an error message, right? Saying, Hey,
24:40
you can actually see pretty nicely here if you can read it. I don't know. But it's saying on the first line you move the value here and on the second line then you tried to use it even though you moved it. Right. Um, and so that's kind of the key essence of rust, right? So let's step back for a second. I just walked you through two examples,
25:01
but what, what kind of just happened between them? Well, what happened was we went from having a compilation error, sorry, we went from having an error when we ran the program to an error when we compiled the program, which we, which is a really important difference. Um, I think systems programming has a reputation also parallel programming.
25:24
They both have a reputation for being very difficult. Right. And I think a lot of the reason is because you set up this structure that seems like it should work just fine, right? But then when you actually put it into practice, you hit problems because there's a lot of unwritten rules that you just have
25:40
to learn or they're written, but they're not enforced, right? There's a lot of rules you have to learn and understand in order to make a system that really works. So there's, there's kind of a deceptive learning curve that happens where you think you've got a system that's working, but you haven't actually learned all the parts. It's kind of like this, right? Uh,
26:01
and so in contrast or what we find is that happens again and again is that it's actually pretty easy to write a kind of high performance API that people can use. The problem is making one that they can use correctly. That's what's really hard. And that's where a rust where ownership and borrowing kind of changes the balance here. Right. Um,
26:23
so in short it kind of makes the difference. Uh, I think if things go right and sometimes they do, you wind up being some somewhere like this, you set up your, your big, uh, you, you try to paralyze your loop. If you get a compilation error or then maybe you refactor things or maybe you
26:42
give up. But if it works, it actually works correctly. Right. And this is why I think people feel or why we find so much more success when you're trying to do these things in rust versus other languages. Um, so, so these are three things, right? We have these zero cost abstractions that let us write really efficient code.
27:04
We have these modern conveniences that let us express patterns more concisely than we used to be able to. And we have ownership and borrowing that let us actually capture permissions. And what I think happens that maybe we didn't expect in the beginning when you have those three things is that something emerges else.
27:21
And I think this is actually the thing that people love about rust. If they love rust, it's that you wind up having this sense of craftsmanship that you can build a really well-crafted library that is kind of simultaneously really efficient and easy to use and catches problems early,
27:41
right? And then on the other side, you can use libraries like that, right? Uh, and you can use them to build your own libraries, which are also well-crafted. So you end up with this kind of beneficial ecosystem. Um, and I think it makes the difference, right? Like you might think that, Oh, it's going to be this kind of great power, great responsibility thing.
28:02
But the responsibility kind of moves onto the compiler. It's handling that part for you. And you just kind of get to have fun building your program, setting up threads that talk to one another or writing parallel loops and so on. And knowing that it's, you're going to be free from like the worst kinds of bugs. Um, so I sent out a tweet the other day asking, you know,
28:23
this is not a leading question at all. Uh, if there are any live, if people have examples of libraries that they really like basically, um, and I got a lot of answers. I don't have them all in these slides. Uh, you know, these are just a few, but it's kind of interesting to look through and look at what these libraries
28:40
do. And it gives you a feeling for all the kinds of things that people are starting to do in rust, right? So you have, for example, well, Saturday, which is you have a kind of a lot of base libraries like Saturday that does serialization, de-serialization. Actually we have one of the maintainers right here looking at me, uh, Daniel Tony, but it's a really cool library that has a lot of flexibility
29:03
for it, um, that people are using. And it also runs, you know, competitively very fast, right? Uh, you can load Jason and de serialize it into a rust structure and just a few lines of code and it will be as fast as if you had handwritten the code for the most part, right? Probably faster because it would be hard to tune it that well. And we have things like rayon that lets you,
29:24
which I was involved with that lets you parallelize loops very easily. Um, then we have higher level things like actics, which is a framework for, like a web framework, um, argument parsing specs. Did anyone attend the games workshop yesterday? Okay.
29:40
You might've worked with specs, which is, it's a engine for, for game engines for storing data and so on. So you can see that people are building all these great building blocks for doing all kinds of things. Not to mention, uh, I should add encryption. Like I don't know what this is. Curve two five five one nine Dalek. But if I knew encryption stuff, I probably would. Um, and so on.
30:02
And they're building all these things and it's really kind of fun to have all these tools to play with. Right. And in fact, I want to highlight one of them because I think it's interesting. It's on the slide, but you can't see it. It's called cross beam. And what it does is it supplies low level parallel primitives. So things like the channel I showed you, well actually a cross beam.
30:23
And there's another one called parking lot, which supplies locks. And these things are kind of, you might think they're boring, but these are like best in class, really efficient locks and channels as well as like cues. And what's cool about them. And the reason I want to highlight them is that you probably don't interact with them directly when you're writing your rust code. Instead, maybe you use rayon that library I mentioned earlier that lets you just take a
30:43
loop and really easily run it in parallel. But rayon uses those things, right? And so it makes building things like rayon or building actics like a big web framework a lot easier if you have these great primitives at your disposal. So you wind up, even if you're not building libraries, using libraries that are doing better than they would have done because they had stuff to draw on.
31:02
So I'm going to pull out this last tweet because I think it kind of captures what I'm getting at. Uh, it's recommending a crate called diesel, which is a database mapping crate. And it says here that it takes, it kind of bridges this dichotomy, right? These two things you had to choose from before either you had a low level database connector before where you were writing SQL kind of directly and it
31:23
was very error prone. Or you could use like an object relational mapper thing that was very high level and had all these layers of indirection and was kind of slow but, but worked. And diesel kind of bridges those gaps, right? It lets you describe the schema and write queries in a rust like syntax that get checked but execute very efficiently and map right down.
31:40
And that's a really cool thing to have in your toolbox. Okay, so there's my four pieces. I think this is the answer to my question. What do people love about rust? I think it's, it's the sense of craftsmanship, but to get that sense of craftsmanship, we had to have these other pieces all come together so you can really support that. But you know, if you're like a keen observer,
32:02
you will see that I said this is it, but I have five puzzle pieces and I've only filled in four of them. Because there's another thing I think that I think is really easy to overlook. Which is what let us do all of these things. What let us get this design in the first place, right? And that's the rust community and it's the community that you're all a part
32:22
of now since you're attending this conference. And rust has always had this long tradition of being open, right? And open is one of those words that everybody says and everybody means something different. So I mean all the things that people are saying, I think for the most part, we are open in a lot of different ways.
32:42
But the one that I think is the most important, especially for, for re for, this theme is that we're open-minded, right? We're always focused on trying to find the best answer. Uh, as I wrote here and not just on winning the argument. And the reason that's so important is that's what's allowed us to kind of get
33:02
from that rust that we had in 2011 when I started that was really a different language to the rest we have now. And so the rust we had in 2011, if you look at it from a technical perspective, it didn't have most of the story I just told you about. We didn't have zero cost abstractions. We didn't have ownership and borrowing. We had some of ownership,
33:21
but not borrowing. Um, and we had a runtime, we had a garbage collector and not a very good one. Um, and you know, it just kind of, we didn't have this sense of extensibility. We had a lot of built in ideas to the language and we didn't have libraries providing those ideas. But we had something else though.
33:43
We had something much more important, which is we kind of had the right goals. We knew we needed it to be fast enough to replace C plus plus like really fast enough. We knew it had however, to also be safe and emphasize correctness because that was the problems we had. And we knew that we didn't know exactly how to do that,
34:02
but that if we were going to find the way there, we needed to have a big community of people contributing ideas and concepts. Right? And so to make sure that happened, we had a code of conduct to ensure that people are treating each other nicely. And we had a culture that was really focused on exploring trade offs, figuring out why are these two things in conflict?
34:23
Can we find a way to bridge that conflict or is it really irreconcilable and so on? Right? And I would say what you, what, what I, if you look over the history of rust, you will find a lot of great ideas. This is a partial list, but what you will not find is one person responsible for all of those ideas.
34:42
And actually if you look at this list, I would say, first of all, they were all introduced by different people, sometimes intersecting sets of people, but different groups. And they all seem kind of obvious. Now if you know rust, well, you're like, yeah, of course we do it that way. But actually they were pretty controversial in most cases,
35:01
or at least in some cases, very controversial, uh, when they came out, right? And they certainly weren't obvious. We didn't, or we would have done them to begin with. I was doing research for this talk and I came across this web, this blog post that I really liked by someone named Jessica Lord called privilege community and open source. You should all go read it. Uh,
35:21
the URL is down there. You can't read it of course, but you can look at the slides later and see it. Um, but it has this cool quote that I liked that I think captures this idea. And it was basically saying, if you're trying to do something that's really, really hard, you need all the ideas from all the people. Right? And that's, I think the spirit that I'm going for it.
35:40
And in case you haven't noticed, like rust is trying to do something really hard, right? Let's just take a moment and watch this lady. Okay. That's really cool. Uh, so, so we're trying to do something that's maybe not quite as hard as that. I don't know, but, but pretty hard, right? When we started out with rust, if you think back, it was like, I used to tell people, what is rust about?
36:03
It's about, we want to have our cake and eat it too. Right. Which in English is like the definition of something that you can't do. Um, we wanted it to be fast. We wanted to be like C plus plus, but also like Haskell and like Java, right? And all these things, it seemed like there were these inexorable trade-offs and we wanted to bridge them. Um, and you know, we kind of did it,
36:22
but we did it only by drawing on all these different kinds of people. And the other thing that's worth emphasizing is when I say drawing on these ideas, it's not just people writing code or when we think about open source, this is from the same blog post. You often think of people writing code, but actually there's a lot of skills that you need to build a language
36:41
just to do the language design itself. You don't want to give the language design to a bunch of type theorists. I think that that's the worst thing you can do. Uh, you do want them in the room, but you don't want them in charge on all on their own because it won't be very usable. You want also teachers and users, um, and users from different backgrounds, JavaScript people, Russ, or well, yeah,
37:01
you probably want Russ people now. Uh, back then I wouldn't say that, but C plus plus people and so on. Right. And you also want people from different domains because you'll find that what seems like the perfect solution to you actually rules out the use case from somebody else's situation. Right. Um, and then I guess it goes a little past that too, right? Not just language design, but if we're going to get people to use the language,
37:23
we have to teach it to them. We have to write blog posts, we have to look at bugs and we have to run conferences. Right. So speaking of that, I'd like to give a round of applause to the Russell atom organizers for making this happen. Um,
37:41
and so a lot of times when I bring this up, people say, well, that's great to have a lot of, a lot of ideas and stuff, but what about designed by committee? Right? What about the danger of like too many cooks in the kitchen? There's all these great expressions for when you get too many people around and the design gets messed up. And I kind of see this as a complicated question. Like it's a real danger.
38:04
I drew this picture. This is from the Odyssey. If you, if you've read it, I'm Greek, so I have to like include at least one Greek myth thing. Uh, but this is the twin dangers that all these say has had to face, right? There's this whirlpool and that's kind of, maybe that's designed by committee. Like there's a real risk that if you have too many ideas and you can't figure
38:21
out how to put them together, you'll just say, well, let's just do it all and you'll end up with this complicated mess. On the other hand, I think there's this other danger that that is maybe represented by what could go wrong. It doesn't necessarily go wrong, but what could go wrong with a like dictator for life kind of model, which is that you can just ignore people's input or not seek it right.
38:40
And you don't know about what you don't know. And you wind up with a system that's not able to really solve problems as well as it could. And the trick is to somehow steer between these, to get the input, but not give into the easy solution of do all the things, but try to resolve it into something that is coherent but addresses all the use cases. And if there's use cases you can't address, then you should do that consciously. Right. And say, well,
39:02
we're not going to handle that and we think that's okay because of X, Y and Z. Um, so that's the trick. It's not easy. I think it's something that we're always working on doing better. Um, but I think it's the right way to go. So that's the full puzzle. Um, I think of what,
39:21
what makes rust rust. And now I hopefully am getting close to the end of my time more or less, but I want to take the last few minutes to talk a little bit about the future, about what I think is up for rust in the next year or two. Like what are our big challenges coming up? And I'm going to start that by looking back at the past at this point that
39:43
apparently is not 1.0, but I'm going to call it 1.0. Um, and saying, think about what, if you were here involved in rust, think about what it was like in may of 2015. Right. We had a core language, but that was kind of it. We had a standard library that was like 90% unstable and not allowed to be
40:01
used on our stable release channels. We had a few, we had you who are using it at Tilda. Well, and the two folks at Tilda, I don't know if we had any other production users. Maybe, I can't remember. Um, but not if, if so, not many. And, uh, and we didn't have, you know, a lot of crates. You can see that. So in the meantime, you know, we did pretty good.
40:23
And I'm going to show this video of this crazy lady again, who's so cool. And, uh, I want you to look at her face when it, when it ends. Because I think, cause I think that's kind of how we, we should feel, you know, um, see if it loads. Yeah. Okay. I like that. It's like, it's like, Ooh, yes, this is what we did.
40:44
You know, and this is really cool. Um, Oh, I didn't mean to watch it again, but that's okay. Uh, but there was a downside to doing all of that, right? We were kind of like a startup, right? We had to prove that this rust thing could work at all. Um, and some, there weren't that many of us as compared to how there is now.
41:01
And that meant, you know, if you had to get it done, you got it done. Didn't matter if you're doing a bunch of other things at the same time. And since then I think we've gotten better. We're like not doing 50 things at one time. We're doing like three and we kind of have a system for how to do it. So it doesn't seem too crazy. It almost works. But, uh,
41:21
the thing is that we're leaving that phase now, right? We've proven that rust can work and now we have to prove that we can handle like all the details and there's a lot of details. Um, we've got to make the compiler faster. We've got to work on various aspects of the language design. We've got to dig into different people's domains and use cases deeply. And it's going to take a while for us to do that.
41:40
And we have to do that in a sustainable way that won't wear us out. And I think an important part of it is we want to do all of that while retaining those aspects of the community that I was emphasizing, while retaining this openness, uh, to ideas and to people and getting contributions from all kinds of people. So in short, I think we want to be like Obama, like, I don't know,
42:02
every way I like Obama, but we want to kind of just be able to have a system where we're like, it's cool. I got this. You know, this, we have a system, we know how to solve these problems. We can address them. Um, and I think that's what we need to be focusing on most of all right now is, is kind of building and organizing all the things that we're doing, um,
42:24
and figuring out how we can do that best. And in the process, also doing of course the things we have to do. And so that's, that's what I'm, uh, personally spending a lot of time thinking about. And I'm going to talk a little bit about that, not a whole lot. Um, but I think it's what we as a project, kind of some of our biggest challenges.
42:42
So an example of this or part of how I think about this is right now we have a lot of things. If you're working on the project, there's a lot of state that's in people's heads, right? So if you want to know what, let's say the compiler team, so like the rust project is broken up into teams and these teams focus on
43:01
different things and there's a team focused on the compiler and, and that team, um, you know, if you want to know what projects they're doing, you kind of have to go ask around, uh, and people know, but at least you did until recently. Um, and that was a kind of a problem because it meant that we had to keep that state in our heads and that was a bit of work that we were doing. Right.
43:20
And if you wanted to get involved, there was a sort of barrier to finding out what's going on and finding out how you can get involved. So I found it useful or I find it useful to kind of step back from the project if you're heavily involved and think about what would it be like if I came to this and I didn't know anything, what could I find out actually? Um, and so on the compiler team, we've been working on this, right?
43:41
We've been adding things we call working groups, which are like groups of people focused on a particular project. We have a repository where we list all the working groups and they have meetings and it tells you like, Oh, if you want to get involved in building this feature that you think is cool, come join this meeting at this time and we'll try to find you a job. Um, and we're working on adding more explicit mentorship pathways and levels.
44:03
So sometimes we would say now we have like official team members who are really knowledgeable and then everybody else. Right. And we would like to have more levels in between saying this person has been contributing for a long time. Um, they can be in a regular, you know, a mid level points to recognize the thing that they've been doing. Um,
44:20
and one of the things I'm coming back to this quote, we saw this quote already about how you need more than people writing code. And one of the things I've seen from doing this work on the compiler team is that even in the compiler team, which you would think of as like the codiest of coders or something, there's actually a lot of roles that are not directly writing code, um,
44:40
that we really need. And I think we should be speaking to people and encouraging people to get involved in these ways. And it's, it's things like organizing meetings. It's things like testing out features, triaging bugs, bisecting bugs. Some of these roles we have ways to fill. Some of them we don't. Um, and I think what winds up happening, the reason when I'm showed you those pictures of people doing a hundred things
45:02
at once, part of it, a big part of it, uh, is stuff like this, right? Is there a few people who to do a lot of this work and it's very tiring and we need to find better ways to distribute it out. Um, so that we can have people as Jessica Lord, I'm just quoting, you could just, I'm just gonna put her whole post in this presentation about time it's done. But as she said, so that people who have only a little time,
45:23
I showed you what an open source whenever can come and do a little bit of each of these tasks, right? A little bit at a time and we can distribute that out and everyone works better. So one thing I want to call attention to if, if any of this organizational thing or the idea of being a part of the rust
45:41
organization itself appeals to you is we're starting up an effort. We call the governance working group. Um, there was a recent announcement. There's a link at the bottom that I'm assuming we'll be able to access my slides. They're all online. You could click it there and or you can just search our internal message board. But the point of this working group is, you know, the compiler team is doing some set of things. Other teams,
46:02
lots of them are doing other things. And this working group is there to kind of talk to the different teams, coordinate amongst them, share ideas and help us design how the rust organization should be structured going forward. Um, so yeah, if you're interested in that, please let me know or come talk to me afterwards. Or Florian is here somewhere. Uh, but anyway,
46:22
so that's what I got to say. I hope you learned something and enjoyed it and thanks for listening. And I'll leave you with these awesome pictures, the last set that I didn't know what else to do with. Thank you.
Recommendations
Series of 12 media
Series of 15 media
Series of 15 media
Series of 15 media