Why Rust is different, with Alice Ryhl

Rust is quietly spreading as a language of choice to build reliable and performant applications. But what makes it different? Alice Real is a software engineer working on Google's Android Rust team. a core maintainer of Tokyo, the de facto async runtime for Rust, and is a Rust language team advisor. In today's conversation, we cover the pitch on why Rust is worth to consider, whether you're using TypeScript or C today.

how concepts like ownership, the borrow checker, and the unsafe keyword work, and what are things that trip up newcomers to rust, how the language is governed without a benevolent dictator, and how RFCs and additions work, and many more. If you want to understand what makes Rust different and why so many engineers say once it compiles it works, this episode is for you. This episode is presented by Antithesis.

Verify your system's correctness without human review or traditional integration tests and avoid bugs or outages. This episode is brought to you by Sentry. Centry is application monitoring software built by developers for developers. The first time I used Centre was 10 years ago, back at Uber, where Centry helped keep us honest on when and where our services were breaking.

I also use Sentry today to help me understand if the services and APIs I built for the pragmatic engineer are healthy or not. Sentry shows you the full context on issues, stack traces, user actions, environment details, and even the exact line of code that caused the issue.

It supports pretty much every modern tech stack, TypeScript, JavaScript, Python, Go, and others. It works on backend, front and mobile, you name it. One new feature Accenture launched is Sear, their AI debugging agent. Let me show you. I open the Seer agent and ask about what are some repeated errors happening on my backend.

Seer figures out that a repeated issue is a network call failure. I can then ask for more details and debug more efficiently with this AI agent integrated neatly into Centric. Seer is a neat tool to fix the hard issues, the ones that are just hard to debug. Check out sentry at century.io slash pragmatic and start monitoring today. Alice, welcome to the podcast. Thank you for having me. It's it's really that nice to have you here. How did you get into software engineering?

It actually all started with Minecraft. I wanted to write my own mod For Minecraft. So I learned Java. I didn't get very far with the Minecraft modding, but that's where it's How did you continue? Did you go to university? This was just before I started in high school and then after high school I had a year where I worked uh full time as a software engineer and then I moved on to start my bachelor. Did that for three years. And then I did a masters for two years.

How did you end up at Google? Was that straight out of university? Actually started part time at the same time as when I started my masters and then I switched to full time after I finished. How do you get involved with the Rust community? Was was it at Google? Was it before Google? Oh way before.

I've been doing Rust for a a long time. When I was in school I spent a lot of time on the what's called the Rust users forum. Well I was answering questions really. I have maybe ten thousand posts on there or something. At some point I also started being active in some chat servers, the Discord server for something called Tokyo. I kept doing that.

Answering questions. When I saw comment questions, I would uh fix the documentation. That's how I got into Tokyo, which I'm now one of the maintainers of. And then for those of us not as familiar with Rust and and Tokyo, uh, what is Tokyo inside of Rust and why is it important? So Tokyo is Well, it's an asynchronous runtime for Rust. You can think of it as the standard library for Rust when you're using async. I mean, if you compare with something like

JavaScript in the browser, you might compare Tokyo with the browser itself. For example in JavaScript you have this loop, this event loop, which has all the tasks that are able to run and then they get executed one after the other. And especially if you use the await stuff, then you can have tasks pause and then another task start running on the same thread. And Tokyo does something similar. It has a queue of selamat menikmati

And then it will run them. So unlike JavaScript, Tokyo can be multi-threaded. So you can have multiple queues running in parallel.

This seems like a pretty core part of of Rust as a language, as a as a ecosystem. How did you gravitate towards this? Because it sounded like you were, if I understand you were lurking on the Rust forums, you were helping out here and there. What drew you to this part of the language or or the ecosystem, should I? I think part of what I liked about Rust is this feeling that

as you write the code, when it compiles, it works. I mean I this has to be in quotes, right? Because obviously it's possible that there are bugs. But this is something a lot of people say about Rust and there's a reason people say it, even though it's not necessarily literally true. How do some other languages compare? To begin with, I think to have a language that feels this way, you have to have a type system. That's where it all starts.

I do think that even compared to other languages with type systems, I think Rust does a better job than many languages, even others with type systems.

I mean the the classic example is Java's null. It was Tony Hare. who invented uh the null and he called it uh his billion dollar mistake. Because it's so easy to have I mean every time you call a function you might have a crash in your program. And in Rust, I think they're really good at making sure that when you call a function, there's no chance that it might be null, right? Yeah. That problem just doesn't exist. So you can't have that kind of crash.

And so you have to explicitly say this object might be null and then the compiler will force you to check for null before you use it. So you can't forget. Like you can in Java.

Can we talk about Rust as as a whole? This was a language that was created in in uh twenty years ago in in two thousand six, and it feels like it's become a lot more popular over time. Do you know of like the scale that Rust is at in terms of usage or popularity or or things that among the Rust Rust community, it's the numbers that are known there. One thing I found kind of funny, I I checked here the other day and uh we have actually overtaken PHP and Go on the Tyobi index. Oh this index.

try to estimate the the usage of languages, right? usage or popularity or something like that. Wow. Because the feeling I have again in general is that rust is popping up in more and more places. More companies are building on rust. Oxide is a good example. They decide to go all in on rust. And like there's a sense of of rust is is becoming

a popular place to build, I guess, high performance applications, even increasingly contributing to to the kernel. As an engineer who, you know, might know other languages from like TypeScript, Java, but as etcetera. What Would your pitch? B on why it's worth checking out Rust or working with Rust. That depends a lot on which language you're coming from. L let's come from TypeScript. It's it's one of the most popular languages right now.

The pitch from TypeScript would be a lot different than the pitch from C. But okay. To begin with, I think when it comes to TypeScript, Rust fits in as the back end language. That's where I would put it. I wouldn't use it in the front end. I think it's a pretty good fit for backends API servers. One way to put it is You don't want to be waking up at night because there are problems with your web server. You need a language that's reliable.

that's gonna have as few bucks as possible. I mean obviously it would be nice if it had zero bucks, but you know, it's gonna be hard to get there. But as few bucks as possible. That's the idea of Rust. I mean I already mentioned null, but it does a lot of stuff like that. So there's no null checking and and this is done through you know it it has this enum type which

I mean I think TypeScript can do something similar. TypeScript is actually kind of good on that front. But but okay. The other thing I think is quite good is uh error handling. So on one hand, Rust doesn't really use exceptions. So it actually returns the error as a value. So you return a value that's either using an enum, either the res result or the error.

And the way this is done is that there's an operator question mark which says so you write my function and then question mark at the end. And this means if this function fails, return the error. So it's really easy to handle errors, but it's not zero characters like it like it is with exceptions, right? So it's explicit. On the other hand, And if you forget to put the question mark, that's a compilation error. Wonderful.

So you have to check it. Yeah. Right? And of course you can also handle it manually. But but the point is, it's this idea of There are these things where you write some code and there's some implicit error condition you didn't think of. And now you just, you know, took on your server or something. And the other thing I would I quite like is how it handles documentation. For one, the

When you have a comment, you make it into a documentation comment by having three slashes instead of two. Now the thing is, you can of course write examples in your documentation. And Rust makes all examples into tests. So this means that if you change the underlying code, now your test fails. And so this means that you can't even you can't forget to update your examples in your documentation. Yeah, and I guess there's also things like y you can you forget to initialize a variable in Rust?

It doesn't allow you, right? You have to set a value before you use it for the first time. Yeah, and I I guess the the things with uh checking the format of incoming Jason it also forces you to do that. Yeah, so there's a pretty cool library called Surday in Rust where you you have your struct, so your type you know with fields, and then you can say, I want to be able to pass this from, for example, JSON. And then Surday will it's a macro, it will generate code.

checks the JSON that it's in the same format it has the all the fields you need and they have the right types and it generates native code that's specific to that particular shape of JSON. So it's also really efficient And again, yeah, and so it helps you avoid errors. And there's this this thing which again I I learned just very recently thanks to uh that thanks to you guys we're talking ahead ahead of this.

is the switch statement, right? So it in almost every language you have a you have a switch for an enum and you handle cases and then you might have a default or a you know like everything else and sometimes you forget. One of them it's not a big deal or maybe it's a big deal. But in Rust you cannot do that either, right? That's right. So In Rust it's not called switch, it's called match, but it's the same idea. You can match on your enum and then you can have a brand.

For each possibility at rant B. And if you are missing one, that's a compiler error. Of course, you can have a catch-all case if you want to. But most of the time you would just list all the cases and then in the future when you add a new variant the compiler will tell you, oh, you need to update your code here, here, here, and here. And I think this is ki kind of leads to another way that Rust really helps. with reliability, which is that if you're refactoring

I think Rust is really good at telling you all the places you need to update. I've done this sometimes where I would refactor something. I change the code, I change the return type or w whatever it is. And then I just fix the compiler errors and un until the compiler stops shouting and then once I've done that I've updated every place I need to update.

I I get a sense that the language designers have thought really hard of what are ways that typically go wrong in a lot of other programming languages? And they just try to fix it through their compiler. Like the documentation example is is the one where I'm still like, wow. Like it happens all the time. Like you you have a comment example or not.

And then it gets out of sync and we always complain about this and we don't know how to fix it. I think we've been I I I know I've been complaining or like for, you know, like a decade. Plus this ROS is the first language where I hear a like an actual solution, even if it's not a perfect one. And I really think this pattern just everywhere you look, you have this kind of thing again and again that

Oh, if you messed up, they you know, either it won't compile, or at the very least there's a lint for it. They just catch a lot of cases at compile time.

And we've had the pitch from TypeScript. or similar languages. What about the pitch from C plus plus? So here I actually think it's even stronger. The thing with C is that if you make a mistake, Right. In in JavaScript maybe you take down your server, w which is already bad enough. But in Z plus, when you make a mistake there

now it's actually a security vulnerability most of the time. Mm-hmm. If you do something as trivial as you did an off by one in your IRA or w whatever it might be, that's a security vulnerability. And that this just keeps happening. Small mistakes become security vulnerabilities. And in Rust, so Rust is memory safe, right? I mean, we talked a bunch about different ways that Rust is more reliable. And we didn't even touch about memory. Let's talk about memory safety.

Memory safety is this idea that no matter how stupid the code you write is, it's not gonna have a certain class of bugs. And this is the you know, the kind of bug that usually leads it into security vulnerabilities. You know, the kind of thing where you read past the array and you just look at random memory.

Or you destroyed an object and then you used it afterwards. So now you actually touch the memory of some other random object. Yeah. And then an attack attacker who figures this out could something there, eventually get that code somehow executed or configuration read, and then boom. Boy, the the classic example in the kernel is let's say you have some object and you manage to make it so that the object that's actually there, right, because the original object is gone.

So the memory got reused and now it has a task struct, it's called. And that's basically your process. And it has a field called user ID.

And it's pretty common for code to write zero zeros to memory. But if you write a zero to the user ID. Now you're root. That's a root user. Yeah. That's a really classic way of exploiting this kind of vulnerability. And then once an attacker manages to do that, they can take over the m whatever your your server or whatever is running. And then of course from there on it can just spiral out of control right now.

Once you're root, you Yeah. Do I understand that a very strong pitch of Rust, especially coming from C plus plus, is memory safety eliminates this whole class of bugs which which are which can turn into security vulnerabilities, which are one of the most serious threats any any any software can have. Lost all of the real reliability ones I mentioned in the beginning. That is a pretty good thing.

Yeah. We just talked about how Rust offers several safety features like memory safety, error handling, and a type system. This is because reliable is not about one thing, but several things at once. This is where I need to mention our presenting sponsor, Antithysis. Like the designers of Rust, Antithysis also believes there's no one silver bullets for reliability. You need many different tools and approaches.

This is why they have released Hegel Rust, a free open source property-based testing library for Rust. Built by the team behind Hypothesis. Rust' compiler is brilliant at catching whole categories of bugs at compile time. But at the edge cases, the weird input combinations, the assumptions that turn out not to hold, those runtime bugs need a different tool. Hegel provides powerful, ergonomic, property-based testing for fast local development.

It'll check edge cases you never thought of and catch unknown unknowns before they bring down production. And if you try Hegel and like it, your Hegel test will run an antithesis as written. So you can easily add determinism and the world's most thorough runtime verification to your reliability arsenal. Go to Hegel.dev to learn more. I'd also like to mention two conferences this year while I'll be talking and where we can also meet.

On the fourth of June, I'll be doing a keynote at Kraft Conference in Budapest, Hungary. This conference is one of the very best ones in Europe, focused on software craftsmanship, and one where I'm a returning speaker. For more details, check out crafts-conf.com. And on the 15th and 16th of September, I'll be doing a keynote at LDX3 in New York. This is the Festival for Modern Engineering Leadership.

Last year, I was at LDX3 in London, and so I'm excited to be back, this time in New York. For more details about this conference, head to leaddev.com. If you'll be at either of them, I'll see you there. And with this, let's get back to Rust and to Alice. I wanted to ask why Rust. is getting so popular, but I think we're starting to answer this question, right? I think where Rust is really unique.

in the combination of things. So on one hand, it it doesn't have a garbage collector and it it's usable in low level contexts, like the Linux kernel or firmware or whatever. Why is it a good or a bad thing to have a garbage collector? Java has a garbage collector, C Sharp has a garbage collector. So a garbage collector says.

Once you've done using your objects, there's gonna be a little piece of code that checks all of your co your objects and says, this is not used anymore, and then it cleans it up. Whereas in languages like Rust or C the variable is cleaned up at the end of the scope when it goes out of scope. And in the other one they have to detect afterwards. And this kind of little piece of code that runs every so often to check all your objects.

For embedded use cases this might simply be not possible or unacceptable.

The the performance overhead, the the fact that you cannot you will not be able to control the memory as much. Even for backend it can be a problem because if you have a request incoming right when it checks all of your objects, like you have some sort of latency spike where you it takes much longer to to reply. So that's one of the reasons it can be helpful in in back end as well. For someone who has not yet seen Rust code, how would you describe it how it compares to, for example, TypeScript?

I mean in many cases Rust code is similar to many of the other languages. It has braces It's not like Python where, you know, you use indentation, it has braces, it has semicolons, and so on. So So it's pretty easy to read, even if you don't under if if you if you know some similar languages, you can look at it and you can get a rough idea. Yeah, I think I think you'll figure it out. It's not that it's not that foreign.

Rust has a a learning curve on the side of the more difficult languages to learn. What do you see devs typically struggle with who on who are new to Rust and and what are the things that just uh makes it click for them? I think the most tricky thing people run into is how should you put together your data structures. I mean for your code you can mostly do the same things as you can in other languages. I mean that's not entirely true but The big thing is really the data structure.

So if you have I don't know what would be a good example, let's say some sort okay, let's just say you have a object for a book. And it has an array of pages, and then you have an object for each page. If I was writing TypeScript, I would probably have a book field in the page that references the book, and then the book of course also references the page. Right, so it's cyclic. So the book goes to the page, goes back to the book. And in Rust, you usually have to design your object.

So that they're not cyclic. It has to be a tree or a deck, if you know what that means. Yeah, yeah, the diary had a async graph. So if you go out and actually b start to use reference counting, it becomes possible to have cyclic objects. Some caveats like you mentioned, but what people end up doing when they're langu learning the language is that they try to make cyclic objects without anything like that. And then it just doesn't work.

And they're gonna run into all sorts of problems in their code while they're constructing they're maybe creating their thing. And then they get a compiler error, and then they try to change the code and they get a compiler error again. But the the thing that a lot of people struggle with is that they keep trying to change the code when the solution is to change the structure. I can see how that's uh frustrating. Rust has another

model that might be new for especially for for people coming from language typeship is Rust's ownership model. What what is the ownership model? Ownership is just the idea that if you have a variable Containing some objects. then the object is only there. It's kind of exclusive. For example, if you have a variable, let a equals your string or whatever, and then you do let b equal to a.

then this is a move. And so this means that using A afterwards is now a compiler error because its contents have been moved away. And of course this is important when we don't have a garbage collector because Then when B goes out of scope, it has to clean up the string. Now if A was also valid, then when they both went out of scope,

it would clean up the string twice, which is not legal. In most other languages the garbage collector takes care of this. A and B just go out of scope, do nothing, and then later it cleans up the string.

But here we actually have to do it when we go out of scope. And the ownership model allows you to move from A to B and then A becomes inactive or unusable and does not get cleaned up because it doesn't have a value to clean up anymore. And how does reference counting relate to all this? In Rust we have a bunch of different types which are essentially different kind of point.

Uh and one of the pointers is it's called arc. It's and it's reference counter. And so the idea is you have some object somewhere, and then you have an arc to the object. And what you can do is you can call clone on the arc, and this increments a counter, and now you have two arcs. To the same underlying memory. So the object might be really big, but you have two arcs that share the same memory.

And when they go out of scope, the counter is just decremented, and when the counter reaches zero, the object is cleaned up. So this is a way of saying, this object actually needs to be in multiple places. There's no one place that owns it. And so this way you can use a counter to know how many owners are there. And then when the last owner goes away, it gets cleaned up. And then Rust also has another thing that was new to me, the borrow check.

So another pointer type we have in Rust is called the reference. And a reference is basically all it is, is that it it's a pointer to the object. And that's it. So we do no checking. So of course this means at compile time we have to make sure that the last use of the reference has to be before the object goes out of scope. And creating a reference is called borrowing, right? The owner owns the value and now we have a borrow of the value, the the reference. And the borrow checkout checks.

That the reference is Like the last use of the references before the object goes out of scope. So if you have say em let's say you have an immutable reference, you're reading, then if you change the object, let's say it's an vector. So I have a mu an immutable reference, I'm reading element five, and then I change the vector I call clear. Then the borrow checker also ensures that you can't use the reference to object five afterwards.

Yes, because now it has been as soon as you change it, it it went out of scope. It's it's now cleared, right? Yeah. ends or starts before or after the previous borrows have ended. So you can only have one rider at the time? Or you can have any number of readers. It checks that on the scope, like in a function.

This concept is is is new to me as someone who's not used Ross Fresh. It's very interesting. One thing I've read is on forums people complaining about f fight so called fighting the borrow checker. What can make it challenging? When you write a c some code that uses the object in a way that doesn't follow the rules I mentioned, that's a compiler error. And fighting the borrow tracker is when you you know can't get out of those compiler errors, I guess.

I think a lot of the time this has to do with the struct. One common mistake I see is that if you have a struct with a reference in it, Rust kind of assumes that it can check the scope of that reference like by just looking at a single function. But if you have your struct and you're passing it over functions, that it might not be possible to make that analysis. And so you just get a compiler error. And so in this case the solution is Maybe to use a different pointer type.

For example, the reference counter pointer type often solves this kind of bug. Right. So the solution is again to change the data structure. Yeah, I'm I'm starting to understand why you mentioned that data structures were a a a place of learning coming from out other languages.

o oftentimes the solution seems to be. Just think about your data structures, understand them and do it in in the Rust way, right? We talked about memory safety, but there is a keyword in in Rust called unsafe. What does this do and in what cases? Do people typically use one? Does it make sense to to to use and why does it even exist? That's just a naive question from me. So let me begin with the what and let's take the why afterwards. So the what is

So unsafe is the escape hatch, essentially. So I explained before how there are certain bugs where if your program has one of those bugs, that's usually a security vulnerability. What Rust ensures is that if you have no use of unsafe, then no matter how stupid your code is, you will never have one of those bugs. Now, if you do use unsafe, then There are still some guarantees, but it's a bit weaker. Because each unsafe operation that you can perform has a list of rules.

And if you violate these rules, then you might end up with one of these bad bugs. But of course if you don't, then you i it's okay. And it's interesting to point out here that unsafe does not disable the borrow checker or anything like that.

It just gives you a few more operations you can perform. that are not safe in general. And so you have to check yourself, yeah, this is actually okay in this particular case to I mean, let's take the vector example again. Normally when you index index five it will say, Oh, let me check the length. So if the length is Six. It's at least sex. Yeah, because it's our zero. Then it's okay otherwise you get a crap But maybe you're writing some super high performance code and you want to avoid this if.

You want to avoid this check or if you're in a loop every time. So so unsafe will just avoid checks. Uh may may that be as if runtime or compile time checks or both. What I would say here is that vector has two different ways of getting a value. There's the you know normal bracket operator we're all used for for other languages, which will do the check and crash your program if you get it wrong. But there's another function called get on chat.

And so if you do write vec dot getunchecked five, then it will give you element five without checking the length. And this function, like in the function signature, it says unsafe fn. That's the function signature. And so you can only call this function from an unsafe block. Got it. So all that the unsafe block lets you do is Call functions mark not C.

And then in practice for sensible use cases of unsafe, is it usually to do with high performance code typically? Or have have you seen like w what what cases have you seen which are like legitimate? This is a great use case for for unsafe? So usually it will never show up in say a back end server. You would have zero uses of unsaved there. Generally when unsafe is used it

to add a new feature to the language. Let's say the language didn't have a vector. The language still has a function to allocate memory, a function to free memory, a function to read at this point or address. Then you could write struct vec the pointer is here and this is a raw pointer, so it's unsafe to use. The length is this, the capacity is this.

So I might ha and then you can write your little API. Of course the fields are private, so you can't access them from outside the module. I mean if I could do vec.length equals twenty, uh just access the field, that would be pretty bad. And so You can write your own vector API and using field privacy and good API design, you can add a vector to the language if it doesn't already exist.

And unsafe if encapsulated properly in this kind of API that doesn't permit you to mess it up, then you can have a safe vector that you can use from safe code. And no matter wh how stupid the thing you do with that vector is, it's not gonna do something bad. It's just gonna crash or whatever, or check the length properly. As long as you design your API right.

you can add new language features by using unsafe. The other classic example would be to call into a C library. You can write a library that calls into C and you can even have a safe API and then you can enforce that you only call the C API in the right way. Can we talk about the the Rust ecosystem, the broader ecosystem? And when it comes to this, the first thing that people come across, including myself, is the crate.

uh ecosystem Rust is package manag manager. What is crate and h how does it compare to other package managers in like places like NPM or or PIP in in Python? So crate is just the rust word for a patch. So it it's just a package, right? Of of of your code. So so the way it works is that Rust has a tool called Cargo. And Cargo is kind of um it does a lot of stuff. It's it's actually a pretty neat tool that's kind of all in one. So it will do

It's both what you use to run your code, you do cargo run and it will compile your code. You have this thing called cargo tunnel, where you specify your dependencies and other information about your crate. And ca when you do cargo run, it will download the dependencies to something called a registry, which is basically just a directory with all the crates you've ever downloaded. Yeah.

And you can also do Kako test. It will run all your tests. Kako doc. It will generate your doc. Kaggot test will also run your doc tests. There's even benchmarks and examples. So so it's it it it does all the the whole suite, so to say. So you don't need different tools to batch dependencies and run your code. I think the biggest c difference from something like P

would be that they're not installed to your machine. Right? Yeah. With pip, you either install things globally or you have these virtual environments. So so with cargo it's all local. You just run cargo run and it Only local to this. The only thing that's shared is this registry, which is just to avoid downloading the same thing twice. You told me a funny anecdote about Linus Tor Worlds and his his reaction or uh what he told you about Rust and Car and Cargo.

The first time I was at the Linux Plumers conference. At the very end, so Linus wasn't the anywhere to sp to be seen throughout the entire conference, but the at the very end at the social event, he showed up and I went over to say hi. I mentioned I worked on Rust. And immediately he started telling me about how he didn't like cargo. And so the reason for that is that cargo downloads code from the internet and runs it.

Like any package manager. Yep. And he doesn't want any any code on his computer to do that other than his uh distributions package manager. He doesn't trust anybody else. In the node world, we're seeing more problems with vulnerabilities being injected into packages. Um just a bad actor overtaking packages, you know, that they they put in whatever code might be from crypto, which is the I guess the better part to security vulnerabilities.

Uh does cargo have this problem as well, just like any package manager that is on the internet? I mean in principle, yeah. I mean ultimately if you somehow got a hold of, you know, my keys to upload new Tokyo versions, you could upload them and it's just one. I don't think we've had much problems with it compared to something like NPM, but I don't really know if we I mean, it's a hard problem, right? It's it's a hard problem.

If somebody can impersonate the maintainer of a library then I mean I I think they do do stuff like delete uh screening malicious crates and stuff like that. Yeah. Yeah, where where do you see the Rust ecosystem being the most mature and the less m and the least mature right now? My opinion is that the least mature area is front end. There have been some attempts to compile Rust to WebAssembly. and then run it on the web uh as a front end, as a replacement for type.

But if I was writing a web server, I would totally use Rust for the backend and TypeScript for the front end. I would not really go the WebAssembly route. On the other hand For for back end, I actually think it's a pretty great fit. And there's also stuff like command line tools. I think it's really, really great fit for that. And then of course we have we are expanding into Linux.

And we're also expanding into a lot of embedded projects and there are even projects that are like C code bases that are starting to say, Hey, it's went into Linux. Maybe we should start using it too. Maybe we should have a memory safe language too. I know that Git is talking about it. I know that CPython is talking about it. There are probably others. Q emo, maybe?

We talk about how the language is is built. Who builds Rust? What the process for for for doing it? How does it compare to a project like Linux? I know it's not a language, but but it's still a large open source project. I mean it's really an open source project. I mean, you may know that Mos that it originally originates from Mozilla, but it's not a Mozilla project anymore. So today there's the Rust project, which has a bunch of different teams.

There's the language team, there's the comp which you don't deal with the language. There's the library API team which deals which decides on the API of the standard library. And these teams kind of govern it. So it's the people who are on these teams that run the language. And one interesting difference compared to some other popular languages l like like Python or

projects like like Linux is they have a benevolent dictator for life and Rust does not. How how is this working and and how are decisions made when especially when they're contagious or when if it could help for you know some just someone to just make a decision.

Honestly, if the team doesn't sign off on it, it doesn't happen. I mean if something is really contentious contentious or really big, it will probably end up being discussed. at a conference. For example, so at there's a conference called Rust Week where they have an event called the Rust All Hands where they're basically taking all of the Rust developers and putting them in one place. So if there was a problem like that, they would probably discuss it there.

And how are these teams structured? So like you said there's a compiler, language, library and and dev tools at at the at the very least. How do they define the boundaries? Is it just a team kind of roughly defining them and then you just kind of ag agree? 'Cause i a as I'm thinking at a corporate level, like

as as a company would run, there's typically teams are are founded often top down. Leadership does a mandate. This will be this team, that team. There's bottoms up happening, but oftentimes it's top down just because it's easier. But here, as I understand, there is no top down. It's it's people self-organizing. Yeah, really when it comes to the design of the language, the teams are really that's really it.

Teams have been pretty good as far as I've seen at delegating. So I've seen them sometimes say, We think this is a lips API decision and we will go with whatever the Libs API decides. One thing that is interesting to talk about is the RFC process. So there's requests for process. I've seen request for comment is the way the Rust project makes big decisions. But you know, big ones is important to say. Basically the way it works

Is let's say you have a language feature that's kind of big. For example, I had one called Drive Smart Pointer, which Basically make some types in the standard library less than So I mean sometimes people begin implementation already, but the idea is that you write the RFC first.

By the way, that that's no different inside of like uh an Uber we had at RPC process and the same thing. Usually you follow it but sometimes you kind of start to build it and then just The idea is you write the the R F first. Yeah, I I know. It happens everywhere where there's engineers, I think. It's ish to build. You write this dog and it has a template and I i i I think it's actually a pretty good template. The idea is

The first section is, I think, motivation. Well, the first one is summary. But the first important one is motivation to explain why this feature. And then I think they have two really interesting sections. They have the guide level explanation and the reference level explanation. And what this is, is that in the guide level explanation, you explain your feature. as if you were writing a guide, as if the feature already existed.

And in the reference level explanation, you explain your feature again as if it already existed, but as if it would be in the language reference instead of a tutorial. This is really interesting. You know, Amazon does Just related to this, when they ask people to build a feature, they have a press release. Like, imagine if you announce this. I just love how like both this and and what you're saying it forces you to

Just think of it from a very different perspective, right? F from from how people will use this feature. And then and then other sections, there's uh I think you mentioned uh rationale alternatives, prior art, future possibilities. Yeah, so th you know, you get to explain. So rationale and alternatives I think is a pretty important section because you get to answer all of the questions before they get asked, and you get to explain why did you s pick this design and some other design.

And I think that's usually a pretty big part of an IFC. And then of course it's good to look at what did C plus plus do? And What can we do in the future? And once you have the RFC, you send it out, what happens then? Well somehow people you get people to look at it. There is an RFC's repository, and you can open a pull request there with your Markdown document with the RFC and people can discuss it.

You might also write up your dog somewhere else. Then we call it a pre RFC if it's not in the RFC directory, but it's kind of the same thing. Let's say that the language team

Like it's a language team RFC and they're happy with it. So I said the RC was how the language makes big decisions. But then they actually use a process that comes up for all decisions essentially, called the final comment period. And so the idea is They tell the bot to please start the approval process and then it will create a comment on GitHub with a checkbox for every team member.

And then team members check their own checkbox and once everybody from the team except for at most two Have checked the checkbox? then the final comment period will begin, which is two weeks. Oh, so... when it's only two check boxes left, then two weeks start. What what's the rationale for this? This is very interesting. It it's a historic fact more more like?

I mean, you know, let's say that everybody checks their bug im immediately and then the two other people didn't get to a chance to look yet. So it's to make sure that everybody has a chance to see it. Yes, I understand. And also to keep things moving at a sensible pace. So there's another part of the process which is concerns. Team members can file a concern, which basically pauses the process until it's resolved. And then once the two weeks pass, it's accepted.

So that's essentially how the team makes decisions. And this is not uh just IFCs. If you have, I don't know, a pull request changing something in the reference. Then the language team might say, Oh, we need to make sure that everybody is on board with this change. They'll tell the bot to start an FCP on this random PR or some random issue or whatever it might be. The same process applies.

And then once let's say it's this language language feature, okay, the RFC is accepted, we know what we're going to build, then the feature is just built. You just start to open your pull requests and get into the language. But you st you put the feature behind a feature flag. In Rust we have this thing called nightly features, which basically means that you can't use it normally.

But if you use the nightly build of the compiler, you can. Once you have your you know, your feature I mean you might begin but you know, once you have your accepted RFC, you start submitting pull requests, uh you implement your feature. and people start using it experimentally. On a nightly build. Yeah. And then at some point

You might say, okay, I think this feature is ready. And this is kind of a recent invention, but we have come up with this idea of a stabilization report. In the pull request that changes that removes the feature flag. we write up a little report saying, for example, how it's been used and explaining like, oh, here are the dangerous itch cases, here are the test

For each of the dangerous it so that kind of stuff. And then They use the FCP process again to agree to stabilize it. And then it's merged. And so now you have a feature without a feature flag in the main branch. Yes. Between zero days and six weeks from that. There will be a beta release of the compiler and it will be Yeah, it will be in it. And then six weeks later, the beta release becomes the next stable release.

Okay. So so like Rust has a strict six week release cycle. Unlike with uh Linux well Linux also has a a rough email, but here you just take the state disable branch, you're not doing any special Yeah, and so we don't really have a concept of beta features that are only available available on beta. You you have the nightly, pretty much nightly, or people can get onto the latest branch which is not yet cut. Yeah, the main purpose of beta.

is to test like you get six weeks to test the stable release. So hopefully if there's any problems we can fix them before it goes out into a staple release. And you mentioned that RFCs are only for large decisions that need to be made and you've you haven't written that many uh either just because they're large. What about smaller decisions that you also want to get consensus on?

So here there are a few different ways to do it. So let's say you want to add a new function in the standard library or a new type. Then the library team actually has this thing called an ACP, an API change proposal. Which is basically just an issue on GitHub. So you open your issue, you describe your API, describe what the interface is, and explain why you should have it.

Uh and it's much smaller than an IFC would be. And then the library team can say this is okay with us. And then you can implement it on unstable. On nightly. And then later you can then stabilize it. And similarly the compiler team has It's kinda fun. Major change proposal? Yeah. MCPs. What is gonna confuse a lot of people outside of who are not inside of Rust? Yeah. It is what it is.

Which are for the small fe smaller features. Yeah. Even though it's called major, right? It's it's big enough that they need you to put up an issue, but not big enough to need an RC. And for the compiler team, the classic example would be a new compiler flag. Now Russ has new new builds every six weeks, right? But it also has additions. There's one in 2015, 2018, 2021, 2024. What are additions?

So the thing about addition that is different from versions is that if you're using version one point ninety of the compiler, everything is using the But different crates can use different editions. And so I might have a crate using the twenty twenty five edition of the language. And I can keep using that forever. Because Rust has a really, really high s backwards compatibility guarantee. So you write all of your code?

The guarantee is that it's gonna keep working forever. That's the idea anyway. Editions are basically the way that Rust makes breaking changes without breaking people. Because they might change the syntax of the language.

For example, async await was added on edition. And so code using the old edition can't use async await. There you could have a variable called async if you want. Let async equal five. And then in the new edition you can't. But you can still mix and match code written in different editions so they work together. Oh interesting. So I might have a library written in the twenty twenty one edition, and you can write your library in twenty twenty-four edition or your binary project.

And then you can still use my library. Why do you think Russ decided on additions, which feels a bit more confusing to me as a developer as opposed to versions. Like when I look at Java's versions or PHP's versions or even Ruby on Rails versions, you know, there's always a might there's a major number and I might be wrong, but it sounds to me that an addition is almost an equivalent of a of a major version at uh not other languages. Is that putting it correctly or am I missing some details here?

Really the big idea is to say we want the old code to continue working, but we still want to change the language. And so the the difference from other kinds of I mean Python two version Python three comes to mind. is that you can totally mix and match in any way you want. You are a language team advisor, uh, or you recently became one. What is a language team advisor? And and what do you do as part of this role?

We have of course the language team, which you know they meet they have meetings every week and they do a lot of stuff and so on and so forth. The language team advisor role is a way to be part of the language team light in some sense. So you're someone that they've said, okay, we trust this person's opinion.

But you don't necessarily go to every single meeting. Like there's no checkbox for you on an FCP. So you can still file a concern. So yeah, it's really a way to participate in or help the language team without full membership. And full membership might entail a lot of things, right? For example, for me it would entail going to meetings every Wednesday evening instead of like when I would normally have dinner. From your observation.

how what is a corporate influence like on on Rust? In the sense that when I talked with with Greg Kh, he was telling me that in practice about eighty percent of the frequent Linux contributors are typically employed by a company which sees value in um adding their their features or or maintaining their features in in Linux, which which turns out to be like a nice kind of I guess symbiosis in in some ways.

for for Rust, uh the the people working on it, are they usually paid by their employers like you are? I I'm I'm sure there's people who are just every now and then contributing, but people who are spending more time on this. Do you see a pattern of corporations actually supporting this or is there a foundation that also uh supports people to work on this full time or close to full time? I would say here that the Linux kernel is truly unique.

in this particular aspect. In that they have thousands of contributors Doing it on work time. I actually think that the Rust project is doing pretty well at having people do it and get paid for it.

like by their employer, but it's nowhere near the to the same extent as the as the Linux kernel. The Rust project also has a few other interesting things. So the Rust Foundation have some grants that allow I mean, for example, if you're a student and you want to work on something, you might be able to get a a grant some money from the Rust Foundation. I I think that's a a super cool Absolutely. That the foundation is doing.

S speaking of which, for for a software engineer who would be interested to contribute to the Rust ecosystem, what would your suggestion be in terms of both resources or or ways to get started? I mean obviously you can go to the issue tracker and look for issues that interest you. I think that often it's I mean the best way to contribute something is if you have something you want to change about. I think that's often a pretty good starting point.

So if you wanted to contribute to the Rust language itself, Rust does a lot of its stuff on this uh something called Sulip. Which is a chat server where people talk and you you could go there and talk to people. So the Rust for Linux project has a pretty nice contributing page. Um so Rust for Linux dot com and there's a contributing page there with for one some of there are a few different um drivers you might be able to contribute to and they have links to the issue tracker there.

Another thing that's really cool is you can contribute to the Linux kernel without contributing to the Linux kernel, right? Because you might take a Rust language feature we need and implement it. And now you've contributed to the Linux kernel indirectly. Or maybe you want to work on the Rust in G C C project and help move that forward. And so I think there are a lot of different projects. Other than the Linux kernel, that would help Rust in the Linux kernel a lot to contribute there.

Can we talk a little bit about Rust in the Linux kernel? On on how that has evolved, how you got involved in in writing Rust in in the Linux kernel? And have you seen the approach of of especially Linux kernel devs uh change or soften towards Russ, because I I know it was a very heated topic earlier on. Linux has this conference called Linux Plum.

you know, as part of my work on Rustville Linux kernel, I've been going through for the past few years. And one thing I think has been really obvious is every time I've gone, you can say Things have totally changed since last year. I've experienced this like four times in a row. That's kind of pretty cool. Yeah, I think there's really a lot of stuff that's happening. I mean, one year I might go and people think, oh, that's some nice little thing you have there, right? And then the next year

Now they have Rust code in their subsystem. It it kind of keeps going. The the the most recent Linux plumbers from December twenty twenty five was their the big news were that

at the Linux kernel maintainer summit we agreed that Rust is no longer experimental in the kernel. That was really big for us compared to the previous year. Yeah. It's official like like Rust has the same status as C, which is the langu the language that the kernel is written in, right? I guess well N not necessarily the same status, but but not be not being experimental, it's it clearly marks that it's more stable. Experimental sounds like it's it's not as stable.

Basically we've proved this is gonna work. I mean based on what you've laid out with m just with memory safety. And of course being able to use unsafe when you need to. It that already like shows a lot of I guess promise. Plus th there's there's some regulation as well, right? There's I think the US Department of Defense passed some regulations saying that they will not allow their agencies to use non memory safe languages.

for the concern of of security vulnerabilities and you know, th this would practically mean that Rust and other memory safe languages could be used, but C C plus plus or maybe one day systems that are built in this one might s see larger scrutiny. Yeah. There have been different stuff like that from multiple different governments, right? These governments are saying, you guys are using C or C++ in this project.

And it's causing an unacceptable amount of memory safety vulnerabilities that simply don't happen if you just don't. So what if you didn't do that? In in his conversation, we managed to go for a very long time without even mentioning AI once, which uh given where the world right now is and and how these tools are are spreading, that that that's pretty impressive.

I I was interested. Do you use any of the AI tools for your day to day work building Tokyo, uh contribute c contributing to Rust projects? Have you found a need for them at all? So I have uh been trying to use them. Honestly, I'm still learning how to use these tools. But I have used them. I I quite like the Gemini command line interface. I think it's uh pretty neat. These tools are

pretty proficient at outputting code or you know giving a prompt and it it putting out code. But in your day-to-day work, how how much code do you actually type as opposed to Reviewing code, thinking about what to do, making a plan. Cause it sounds like as as we're talking about the RFC, for example, with the RFC process, my sense was that most of that was thinking about what to build, getting a consensus.

making sure it's right. And it almost sounded like the actual code itself would be the, I don't know, lesser of course, you know, there's a lot of work involved, but you see what I mean? The the actual time spent will probably be less than everything else around it. I think it's still an important part of the the process. I mean a lot of people talk that about that when you use AI

it's really important to write tests and that kind of thing. Because then the AI is actually able to tell if it did it right. I explained this story from before about how I re was refactoring something. I just told did what the compiler told me. I think the k same kind of principle applies with agents in that they can talk to the compiler, it will tell them what to fix.

So I guess this could be a case, we'll we'll see, but Rust could be a pretty promising candidate for to use for agents because they can get more feedback and it's just har it's harder to to ship certain type of bugs or maybe impossible to have certain type of bugs. Yeah, I think there is a aspect of that. For places like the Linux kernel, where I mean, cr correctness is extremely important, reliability is very important, there's already multiple layers of human review which which is is in place.

Do you see potential for AI generated code to prove helpful somewhere? Like like actually truly helpful. Like again, assuming that these things can generate, you know, SPRA specification or as per what what what you need?

Or or could could this be a place where like it might be m one of the places where we might not need that much?'Cause it's it already feels a kernel to me it feels like a place where there's a lot of people coming in, contributing and and there's There's a reason that change can propagate slower. When I was at the Linux Kernel Maintainer Summit, one of the topics that came up was using AI for code review.

And there were some people there who had, for example, set up buts that would say when you send an email to the mailing list, it would feed it into an AI agent which would leave a review. that kind of stuff. And for example, Linus and others were talking about how these reviews were actually really impressive. for kernel code. At least what's being discussed in the kernel community, that kind of use case seems Like something people are excited about.

And it sounds like this would not be a replacement obviously, but just one more way to get feedback, maybe doing quicker and and just an additional safety net, if you will, right? mean that's the thing with memory safety, right? you make some sort of trivial mistake. It it's not some complex thing. It's just you make some trivial mistake and there's a mil bajil bajillion places you could make it

So even if even if you're a really good programmer and only make it point one percent of the time or whatever, it's still gonna happen. Right? And so if the AI can catch a lot of those, then, you know, that's pretty good. Mm. Well and I I guess some creative use cases could be, for example

their tests are are a big thing, but AI might be able to help figure out if there's edge cases missing again, if if the language itself does not support it. But there could be what I understand and there's there could be a lot of potential to add more safety nets that do not exist today. I think that's right. I like this approach. Uh so this is this is one of the first conversations I'm having where we're talking about AI.

We're we're talking about how to increase quality with with AI because in again in in startups or whoever is building, there's a lot of talk about how it can make it faster, faster iteration. And there's usually a quality trade off that we usually do not talk about. But I I love that we're actually talking about the things that can increase quality or or at le at least keep it at the same level.

I mean I have actually written a few patches with AI myself. It worked okay. Some I mean, it definitely required my review before sending it out to the list. It really did sometimes. But you know, a another place I remember using it was I had this commit that m made Binder faster in some way. And one of the review comments I had received was, Hey, can you run a benchmark?

I said, oh my god, now I have to write a benchmark. But then I got the AI to benchmark it for me. And what it did, what it actually went and found an existing benchmark and modified it a little bit. in a quite clever way and then it ran it for me and then it wrote a Python script to analyze the text file with the numbers and presented it in a nice table.

So it sounds like this was toil work that you could have done, but you might have not done as good of a work because you might have not found that uh utility, you might have not not figured out to do that. I mean, at least in that instance it saved me time, if nothing else.

For a senior engineer who would like to learn Rust or, you know, just build with it, what would your suggestion to be to get started? Of of course, for example, AI might be w one of the things which which makes it a lot easier just to to get started. But if if you would like to learn what do you recommend for for people who actually want to become professional at the language? So for one I would say that the Rust book Which is

So it's on the official Rust website. It's actually really good. Right? And you don't have to it's freely available online. Rust has this idea of calling tutorials for books for some even so they're online, which is kind of funny. But anyways, I think the Rust book is really good. Other than that, I think honestly the way you learn a language is you have you have a project. You you implement some sort of project, with it I mean Maybe some sort of web server or something.

And one more thing on AI. So it's easy to get started with languages these days because you can just prompt the AI to like write this or that.

In the case of Rust, do you think that could create a false sense of understanding? Especially we talked about the importance of understanding structures, of you know, understanding compiler issues which are there for a reason. You know, tools could just like generate through this and create code that that runs.

Yeah, i it's totally a danger. I recently tried using it for something where I guess I was not writing Rush code, I was writing make files. I wanted to add some support in the Linux kernel build system for for some feature, and it went into the make file and added the Rust flags necessary to do it. But then I looked at the code and it was it had added the necessary build flags.

But to the seaside it was passing a few more flags which were not required per se, but they were there for a reason, and it had just ignored them. Any human looking at this would be like, Why did you add Rust versions of all the flags? What is your favorite Rust feature, if there is one? I'm currently working on a new feature which I think is really exciting. It's something that k that we ran into in the Linux kernel.

where we needed in place initialization, the ability to construct values while knowing where they're being constructed so they don't get moved afterwards. I'm pretty excited about our work to put that into the language, but it very much ongoing. I I think that's pretty cool stuff. And as as closing, what are what are books you would recommend that you've enjoyed and and why? I

I already mentioned the the official Russ book. I also think that so John Gangst has a another book that I think is really good and this book is kind of aimed at the intermediate Rust developer. The the Rust developer who has gotten some Rust experience but wants to go further. I think that also a pretty good book for for that audience. Some other resources which are not books, but which I think are also really good is there's this thing called wrestlings.

And the idea is that they give you some unfinished Rust code and your task is to finish it. And I think that's a pretty cool way to learn the language as well. अवसम् Alice. Thank you. Thank you so much. This was really interesting and I've learned about it. Thank you for having me on. I hope you enjoyed getting into the details about Rust as much.

One thing I appreciated talking about is how deliberately Rust seems to have been designed around the question: what mistakes do programmers actually keep making, and how do we eliminate those mistakes? A few examples include memory safety, not having a null, and the errors being values that you cannot ignore. The documentation example is also an interesting one. Documentation tests, or doc tests, are automatically run as tests.

If your example breaks, then your bill breaks. This is the first time I've heard this clever idea implemented in a way that's easy to use in a language. Finally, the question on why Rust is becoming so popular might be because it's in a category that did not exist before, a language that's reliable and also performant at the same time. This makes it usable for high-performance computing cases like kernel work.

while also being a good alternative for higher-level backend languages. Do check out the show notes for related the Pragmatic Engineer deep dives that go even deeper into back-end topics and stories of building languages like Koughlin and Swift. If you've enjoyed this podcast, please do subscribe on your favorites podcast platform and on YouTube. A special thank you if you also leave a rating on the show. Thanks and see you in the next one.