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 are 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 languages govern 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. Sentry is application monitoring software built by developers for developers. The first time I used Sentry was 10 years ago, back at Uber, where Sentry 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, frontend, mobile, you name it. One new feature Sentry launched is SEER, 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 Sentry. SEER is a neat tool to fix the hard issues, the ones that are just hard to debug. Check out Sentry at sentry.io slash pragmatic and start monitoring today. Alice, welcome to the podcast. Thank you for having me. It's really nice to have you here. How did you get into software engineering? It actually all started with Minecraft. No way. 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 started. How did you continue? Did you go to university? This was just before I started in high school. After high school, I had a year where I worked full-time as a software engineer, and then I moved on to start my bachelor. I did that for three years, and then I did a master's for two years. How did you end up at Google? Was that straight out of university? I actually started part-time at the same time as when I started my master's, and then I switched to full-time after I finished. How did you get involved with the Rust community? Was it at Google? Was it before Google? Oh, way before. Way before. I've been doing Rust for a long time. When I was in school, I spent a lot of time on what's called the Rust Users Forum. Well, I was answering questions, really. I have maybe 10,000 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 common questions, I would 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 Tokyo, what is Tokyo inside of Rust, and why is it important? So Tokyo is 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 it 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 starts running on the same thread. And Tokyo does something similar. It has a queue of things that are able to run, 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 Rust as a language, as an ecosystem. How did you gravitate towards this? Because it sounded like you were, if I understand correctly, you were lurking on the Rust forums, you were helping out here and there. What drew you to this part of the language, or the ecosystem, should I say? 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, 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 all those with type systems. I mean, the classic example is Java's null. It was Tony Hare who invented the null, and he called it 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? 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 a whole? This was a language that was created 20 years ago, in 2006. And it feels like it's become a lot more popular over time. Do you know of the scale that Rust is at in terms of usage or popularity or things along the Rust community, the numbers that are known there? One thing I found kind of funny, I checked here the other day, and we have actually overtaken PHP and Go on the TIOBE index. Oh, that index tries to estimate the usage of languages, right? Usage or popularity or something like that. Wow. Because the feeling I have, again, in general, Rust is popping up in more and more places, more companies are building on Rust. Oxide is a good example. They decided to go all in on Rust. And there's a sense of Rust is becoming a popular place to build, I guess, high performance applications, even increasingly contributing to the kernel. As an engineer who might know other languages from TypeScript, Java, etc. What would your pitch be on why it's worth checking out Rust or working with Rust? That depends a lot on which language you're coming from. Let's come from TypeScript. 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. So to begin with, I think when it comes to TypeScript, Rust fits in as the backend language. That's where I would put it. I wouldn't use it in the frontend. I think it's a pretty good fit for backend 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 going to have as few bugs as possible. I mean, obviously, it would be nice if it had zero bugs, but it's going to be hard to get there. But as few bugs 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 this is done through, you know, 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 okay. The other thing I think is quite good is 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 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 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. And of course, you can also handle it manually. 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 down your server or something. And the other thing I quite like is how it handles documentation. — How does it? — For one, 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. 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, can you forget to initialize a variable in Rust? — I mean, no. — It doesn't allow you, right? — Yeah, you have to set a value before you use it for the first time. — Yeah, and I guess the things with checking the format of incoming JSON... Try Haggle and like it. Your Haggle tests will run in antithesis as written. So you can easily add determinism and the world's most thorough runtime verification to your reliability arsenal. Go to haggle.dev to learn more. I'd also like to mention two conferences this year where I'll be talking and where we can also meet. On the 4th of June, I'll be doing a keynote at Craft 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 craft-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 is in the combination of things. So on one hand, it doesn't have a garbage collector, and 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 going to be a little piece of code that checks all of 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 performance overhead, the fact that you will not be able to control the memory as much. Even for back-end, 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 it takes much longer to reply, so that's one of the reasons it can be helpful 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, it's pretty easy to read, even if you don't, if you know some similar languages, you can look at it and you can get a rough idea. Yeah, I think you'll figure it out. It's not that foreign. Rust has a learning curve and it's on the side of the more difficult languages to learn. What do you see devs typically struggle with who are new to Rust and what are the things that just kind of 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 structures. So, if you have, I don't know what would be a good example, let's say some sort of, okay, let's just say you have an 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 objects so that they're not cyclic. It has to be a tree or a DAG, if you know what that means. Yeah, yeah, the direct acyclic graph. So, if you go out and actually start to use reference counting, it becomes possible to have cyclic objects with some caveats, like you mentioned. But what people end up doing when they're 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 going to run into all sorts of problems in their code while they're constructing, they may be 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 thing that a lot of people struggle with is that they keep trying to change the code when the solution is to change the struct. I can see how that's frustrating. Rust has another model that might be new for, especially for people coming from languages like TypeScript, is Rust's ownership model. What is the ownership model? The ownership is just the idea that if you have a variable containing some object, then the object is only there. It's kind of exclusive. So, 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 pointers. And one of the pointers is, it's called arc, and it's a reference counter. And so the idea is, you have some objects 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 checker. So another pointer type we have in Rust is called the reference. And a reference is basically, all it is, is that it's a pointer to the object, and that's it. So we do no checking at runtime. So of course, this means that 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 reference. And the borrow checker checks that the reference is, like the last use of the reference is before the object goes out of scope. So if you have, say, let's say you have an immutable reference you're reading, then if you change the object, let's say it's a vector. So I have an immutable reference I'm reading element 5, and then I change the vector. I call clear. Then the borrow checker also ensures that you can't use the reference to object 5 afterwards. Yes, because now it has been, as soon as you change it, it went out of scope. It's now cleared, right? Yeah. The way it works is that if there are mutable borrows, it ensures that the mutable borrow ends or starts before or after the previous borrows have ended, basically. So they don't overlap. So you can only have one writer at the time or you can have any number of readers. It checks that on the scope, like in a function. This concept is new to me as someone who's not used Rust before. It's very interesting. One thing I read is on forums, people complaining about fighting, so-called fighting the borrow checker. What can make it challenging? When you write 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 checker is when you 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 by just looking at a single function. But if you have your struct and you're passing it over functions, then 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. So the solution is, again, to change the data structure. Yeah, I'm starting On the Internet and runs it, like any package manager. Yeah. And he doesn't want any code on his computer to do that other than his distribution's package manager. He doesn't trust anybody else to do that. In the Node world, we're seeing more problems with vulnerabilities being injected into packages, just a bad actor overtaking packages, you know, they put in whatever code might be from crypto, which is I guess the better part to security vulnerabilities. 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 my keys to upload new Tokyo versions, you could upload a malicious 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? If somebody can impersonate the maintainer of a library, then, I mean, I think they do do stuff like delete, you go scratting malicious crates and stuff like that. Where do you see the Rust ecosystem being the most mature 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 as a front-end, as a replacement for TypeScript. 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 backend, I actually think it's a pretty great fit. And there's also stuff like command line tools. I think it's really, really a 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 C Python is talking about it. There are probably others, QEMU maybe. Can we talk about how the language is built? Who builds Rust? What's the process for doing it? How does it compare to a project like Linux? I know it's not a language, but it's still a large open source project. I mean, it's really an open source project. I mean, you may know that Mozilla, that it originally originates from Mozilla, but it's not a Mozilla project anymore at all. So today there's the Rust project which has a bunch of different teams. There's the language team, which, you know, deals 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 like Python or projects like Linux is, they have a benevolent dictator for life and Rust does not. How is this working and how are decisions made when, especially when they're contagious or when 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 or really big, it will probably end up being discussed at a conference. For example, so 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 dev tools at the very least. How do they define the boundaries? Is it just the team kind of roughly defining them and then you just kind of agree? Because as I'm thinking, at a corporate level, like as a company would run, there's typically teams 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 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 lips API decides. One thing that is interesting to talk about is the RFC process. So there's Request for Process. RFC, 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 derive smart pointer, which basically makes some types in the standard library less special. So, I mean, sometimes people begin implementation already. But the idea is that you write the RFC first. By the way, that's no different inside of like a Uber we had an RFC 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 RFC first. Yeah, I know. It's just funny how it happens everywhere where there's engineers, I think. It's an itch to build. You write the doc and it has a template and I think it's actually a pretty good template. The idea is the first section is, I think, motivation. The first one is summary, but the first important one is motivation. So you explain why did you pick this design and not some other design. And I think that's usually a pretty big part of an RFC. And then of course, it's good to look at what did C++ do and what can we do in the future as well. 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 RFCs 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 doc somewhere else and 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 RFC 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 their checkbox, then the final comment period will begin, which is two weeks. Oh, so when it's only two checkboxes left, then two weeks starts. What's the rationale for this? This is very interesting. It's a historic fact more like. I mean, you know, let's say that everybody checks that box immediately and then the two other people didn't get 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 just RFCs. 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 wherever it might be. The same process applies. And then once, let's say it's this 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 request and get into the language. Pretty much. But 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, you implement your feature. Frequent Linux contributors are typically employed by a company which sees value in adding their features or maintaining their features in Linux, which turns out to be a nice kind of, I guess, symbiosis in some ways. For Rust, the people working on it, are they usually paid by their employers like you are? 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 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 by their employer, but it's nowhere near to the same extent 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 grant, some money from the Rust Foundation. I think that's a super cool thing that the foundation is doing. Especially, I think, getting people in both students involved or, you know, the people who would find it harder or more daunting to get involved in a project like this. Speaking of which, 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 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 it. 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 something called SULip, which is a chat server where people talk and you could go there and talk to people. So the Rust for Linux project has a pretty nice contributing page. So rustforlinux.com and there's a contributing page there with, for one, some of there are a few different 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 GCC 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 how that has evolved, how you got involved in writing Rust in the Linux kernel, and have you seen the approach of especially Linux kernel devs change or soften towards Rust? Because I know it was a very heated topic earlier on. Linux has this conference called Linux Plumbers, which, you know, as part of my work on Rust for the Linux kernel, I've been going to 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 kind of keeps going. The most recent Linux Plumbers from December, 2025, was there 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. So now that means that it's official, like Rust has the same status as C, which is the language that the kernel is written in, right? I guess, well, not to say the same status, but not being experimental, it clearly marks that it's more stable. Experimental sounds like it's not as stable. Basically, we've proved this is going to work. I mean, based on what you've laid out with just with memory safety, and of course, being able to use unsafe when you need to, that already like shows a lot of, I guess, promise. Plus there's some regulation as well, right? There's, I think the U.S. Department of Defense passed some regulations saying that they will not allow their agencies to use non-memory safe languages for the concern of security vulnerabilities. And, you know, this would practically mean that Rust and other memory safe languages could be used, but C, C++, or maybe one day systems that are built in this one might 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 this conversation, we managed to go for a very long time without even mentioning AI once, which, given where the world right now is and how these tools are spreading, that's pretty impressive. I was interested, do you use any of the AI tools for your day-to-day work building Tokyo, contributing to Rust projects? Have you found a need for them at all? So I have been trying to use them. Honestly, I'm still learning how to use these tools, but I have used them. I quite like the Gemini command-line interface. I think it's pretty neat. These tools are pretty proficient at outputting code. You know, giving a prompt and it putting out code. But in your day-to-day work, how much code do you actually type as opposed to reviewing code, thinking about what to do, making a plan? Because it sounds like, as we're talking about the RFCs, for example, 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 actual time spent will probably be less than everything else around it. I think it's still an important part of the process. I mean, a lot of people talk 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 was refactoring something. I just did what the compiler told me. I think the 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 where we'll see, but Rust could be a pretty promising candidate to use for agents because they can get more feedback. And it's just harder to ship certain types of bugs or maybe impossible to have certain types of bugs. Yeah, I think there is an aspect of that. For places like the Linux kernel, where, I mean, correctness is extremely important. Reliability is very important. There's already multiple layers of human review, which is in place. Do you see potential for AI generated code to prove helpful somewhere? Like actually truly helpful. Like again, assuming that these things can generate, you know, as per specification or as per what you need. Or could this be a place where it might be one of the places where we might not need that much? Because it already feels the kernel, to me, it feels like a place where there's a lot of people coming in, contributing. And 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 bots 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 do it quicker and just an additional safety net, if you will, right? I mean, that's the thing with memory safety, right? You make some sort of trivial mistake. It's not some complex thing. It's just, you make some trivial mistake and there's a bajillion places you could make it. So even if you're a really good programmer and only make it 0.1% 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. Well, and I guess some creative use cases could be, for example, there are tests are a big thing, but AI might be able to...