落ち着いて clone を呼ぼう：Rust の安全性と AI エージェント時代の役割

For solving difficult problems is what drives you, Raytheon is hiring software, systems, and hardware engineers to take on some of today's most complex technical challenges. Explore opportunities at careers.rtx.com forward slash Raytheon. It's forward slash R-A-Y-T-H-E-O-N. Hello, everyone, and welcome to the Stack Overflow podcast, a place to talk all things software and technology. I'm your host, Ryan Donovan, and today, as part of the results of our Stack Overflow developer survey, we're talking about Rust, one of the consistently most loved languages on our survey. And for that, my guest is Josh Triplett, who works on the Rust language and is part of the Rust leadership team. So welcome to the show, Josh. Great to be here, Ryan. Thanks for having me. So before we get into the rest discussion, we'd like to get to know our guests.

How did you get into software and technology? So I've been interested in software and technology since I was very small and needed to sit on my father's lap to reach the keyboard of an original IBM PC. Learned on DOS at some point right around 15, I discovered that Unix wasn't just a thing that ran on mainframes. and over the next handful of years started switching myself over to Linux and was more or less fully switched to Linux by, I want to say, around 2003. I have been deeply enjoying technology. I'm largely a technophile and a neophile. I enjoy almost all things innovation. And I was excited about computers ever since, feeling like this box can do anything that I could possibly imagine as long as I know how to make it do so. Like, it's limited only by my imagination. And that was, I was immediately hooked.

And then I've been interested in Rust for around the last, I think, 11 years or so now. I've been involved with that and very excited about that. I got some early information about it from the Planet Mozilla blog aggregator when it was first being played with. And when I first looked at it, it was like, what is this weird language with all the sigils? But they're saying interesting things about ownership and borrowing and memory. And, hey, what if you didn't have to free this memory? And I was a C programmer going way back. I enjoy a variety of other languages like Python and Haskell, but very much knew the low-level machine. And so the idea of, hey, this is interesting. Yeah. Rust has always been an interesting one to me because it does have those sort of features that you don't really see in other ones. The borrow checker is definitely a big one. So I think maybe we'll start there. That may be one of the things that people know about Rust. So why does Rust have a sort of different way of managing memory and almost garbage collection?

Sure, absolutely. So for the most part, prior to Rust and leaving aside some notable research languages that fed into things like Rust, languages tended to fall into two major categories. There were the low-level languages that were C-like and similar and gave you a lot of control of the low-level machine. You knew where things were placed in memory. You can have pointers and work with raw memory and allocate and deallocate and know that nothing's happening behind your back. But they didn't tend to have very good convenience features. They were razor-sharp edges, all that kind of thing. And then all the myriad high-level languages that were easier and more fun to program in but gave you less control and you're not going to write an operating system in them except as a stunt or a browser or a JavaScript engine or similar. And those worked well and were nice contrasts, but the main thing was you didn't really have, you had to pick between those, and that was a bit unfortunate.

So one of the things Rust really has going for it is that we really often will say things like, you know, this or this, pick both. Or this, this, and this, pick all three. And so we're trying to offer the features of a really high-level language that's still giving you all of that control, and that has been part of why it's been able to take off in so many areas. But for borrow checking in particular, the way it was pitched to me when I was first reading about it was effectively, well, it acts like you're writing something like C, but it will figure out when you have stopped using something and automatically call free for you, or we call it drop. And so one of the issues with garbage collection is that it will either use something like reference counting and add some type of overhead and not handle cycles or similar, or it will run in the background, interrupt what you're doing, add latency, that type of thing. And so we're kind of a compile-time garbage collection mechanism almost.

And then we have ways to opt for other things, like if you want reference counting, we have a type for that. It's interesting, memory safety has become a lot more important, or at least on people's radar. I saw something from the White House saying, like, stop using memory unsafe languages. Absolutely, yeah. Make a plan for by the end of a given year for you need a plan for migrating away from memory unsafe languages, yes. and seems somewhat prescient now with the massive trend of let's scan for security vulnerability so fast that disclosure windows are mostly just not a thing. Yeah. I've also heard people complaining about the borrow checker, trying to wrestle with the borrow checker. What do you think is the sort of hurdle for people to understand how to use variables in scope with that? So I think there's two aspects to it when people talk about fighting with the borrow checker. And one aspect of it is that you kind of pay all the pain up front.

We try to make it as painless as possible, but imagine taking all the pain that you might experience at runtime with having a memory violation that you're chasing down and compressing all that pain into compile time, which tells you both why the compile takes a little time and why you end up fighting that a little bit before you get a program, because Rust half-jokingly, half-seriously has a reputation of, oh, it compiles, it must be correct. And as much as that isn't exactly true, it's shocking how often it is. Yeah, because you get more warnings and errors for the compile. Exactly, yes. And people grow to find, like, the compiler is not nagging you, the compiler is your friend in this case. And oftentimes, I will get an error message from Rust and be, you know, I will be reminded of the kind of code I used to write and think, boy, that's a, you know, a truck I almost stepped off the curb in front of.

Right. But the other aspect of it, I think, is if you are writing with some other language in mind, there is a, you know, since before there were like since before I was around, there were jokes about like you can write Fortran in any language. You can write C in any language. You can write Perl in any language. Like, if you are writing with another language's fundamental model in mind, then you may encounter friction when you try to push that model into Rust, saying, oh, I know how I'd do this in C or in C++. I would stick a pointer here. Why doesn't the compiler accept that there's a pointer here? And the answer is because we can't prove it's correct. A lot of that reputation also developed from the early versions of Rust that were very conservative about this. And the first borrow checker was correct, but it would often not let you get away with things that you can look at and say, but I know that's correct. Why don't you believe me, compiler? And we got one round of improvement with what was called non-lexical lifetimes,

where the compiler could actually tell, you've stopped using this thing, So now you can do it in this other way and those two things won't conflict. And we're making it even more advanced now. So more and more, it is the case that the line of programs that are actually incorrect and programs that are correct are close together, where the gap in the middle of programs that are correct, but the borrow checker can't tell is narrower and narrower. And that helps people feel less frustrated with it. Right. So, I mean, obviously, Rust is more than just the memory safety and the borrow checker. It consistently gets a lot of love in our developer survey. This year, I think 18% of the respondents had used it, but 26% want to use it. Right. Why do you think it's sort of the most loved language for people who use it? So I think there's a few things that come into play there. One is that aspect of once you've gotten used to it, it feels very comforting and protective in terms of look at all these things it's catching for me that I don't have to worry about.

It provides a kind of psychological safety where it's like I am free to experiment. I am free to do complicated things. There was years ago a bunch of work out of Mozilla's browser team, and other teams have reflected the same thing where they effectively said, we would not have felt comfortable writing this in C++. You see people in Rust just saying, I'm going to go write a bunch of fancy SIMD code. I'm going to go write really complicated threading code. And it just works. And it just works on the first try where people were afraid to build that, not because they didn't think they could do it, but because they anticipated all the pain that would come up when they're debugging it. And so it makes people feel fearless because they feel well-protected. There's a phenomenon where, like, seatbelts made people drive faster, but unlike with cars, it's okay if you drive faster with rust. It'll be right there for you. Right. The compile time failure means that, you know, you're not going to get something that slips through secretly haunting you for years, right?

Exactly. And there's a few other aspects of it as well that I think keep people coming back. One is that we are the whole industry is improving in this direction but Rust has been particularly welcoming and inclusive towards people And that reputation kind of radiates outward and set the tone of a lot of the early and mid community around Rust And so a lot of people who didn't feel like they had a home elsewhere felt right at home in Rust and started doing really fun and creative things. And then on top of that, I think that it is that bit about we fit that intersection of two classes of language that you wouldn't normally expect, where all of a sudden instead of, well, I have to do this bit in this low-level language and I get to do this bit in this high-level language, there is a certain feeling of, oh, I get to use Rust and I get to use Rust. and so people who learn it and enjoy it find themselves able to use it in more places where

they previously were you know if you fall in love with python it's a beautiful language i really enjoy python it's my second favorite language and still the one i go to for having a repl on the command line but if you fall in love with python then you find that like well i can use python in most places but i can't go use it as conveniently on the web i can't go use it to write a web browser, I can't write an operating system. The number of times I've been impressed and surprised with where people have managed to fit Rust has been just endlessly delightful, and the surprises have not ended. So what is the most surprising thing you've seen people write in Rust? At this point, a lot of my surprises are, oh, awesome, there's Rust there. Like a few years ago, it was, oh, there's Rust in the Windows kernel, a place you would expect to be pretty conservative about it. There's Rust in low-level virtual machines. There's people doing Rust in EFI firmware. There's things like the GetVersion control system where it's not surprising that you could write it

in Rust or any number of other languages. It's surprising that they are willing. So in one sense, from a social point of view, the most surprising place I see it is steadfast, like, you'll take see out of our cold dead hands projects. The other is places like watches and satellites and like embedded platforms, high assurance platforms, cases where, oh, wow, we can actually let people use Rust there and feel safe using Rust there, and that's delightful. Yeah. I mean, I imagine, you know, to go back to the borrower checker, for those embedded languages, is there's no overhead for garbage collection or memory safety because it's all stopped at the compiler side. Is that accurate? That's more or less accurate, yes. We like to talk about zero-cost abstractions where you don't pay for anything you're not using. So if you want a reference-counted pointer, you create one and you get a little bit of overhead of reference counting. If you use entirely the borrow checker,

you get entirely the borrow checker, and it doesn't cost any runtime overhead. Though there's a thing that I like mentioning to people as well, where it's like people get really excited about Rust, and they get like, oh, I should use borrowing everywhere and never copy anything and never clone anything. My program will be beautiful and low overhead, and you can end up pulling your hair out that way. And you can write in Rust incredibly well-optimized, low-level programs that know exactly where everything is placed and deal with all the details. and I love that you can do that and also you are not required to do that and please feel free to I have a sticker on my laptop that says keep calm and call clone you can call clone, you can use ARC you can use a mutex or an rwlock you can write Rust as a safer, more comfortable C, but you can also write Rust as a somewhat faster still high level Python

and you will end up with code that's still pretty well performant and, okay, sure, it copied a few strings instead of borrowing them. So what? Your code's written now and it's working and you can profile it and optimize it later. So I don't want people to feel like, oh, this can be perfectly optimized. I must be a perfectionist. Right. I think it was, was it Jeff Atwood talked about performance as a feature? Joel Spalski is one of our founders, had a performance as a feature sort of thing. And it's like, well, you don't have to focus on that feature from the outset, right? Absolutely. And there's a great quote from Austerhout that says, the greatest improvement in performance is from the non-working to the working. And we really like enabling that in Rust just as much as we like the people who are, look at this massive parallel SIMD-enabled program I'm running on this 128-way Threadripper. Right, right. I know Rust also has pretty significant interoperability features,

and it has the cargo crates, the sort of like portability, interoperability. How has that sort of helped Rust along, and how do you see that working with the larger ecosystem? So I think that having a strong FFI and a strong interoperability story, a foreign function interface, like something to call or be called by C, is a really important part of any language that wants to be close to universal. If you want to run with anything or in the context of any program, you don't want to say all or nothing. You don't want to say, oh, if you rewrite everything to Rust, like rewrite it in Rust, it's a meme. It's not an advocacy. Like, please, the Rust evangelism strike force, you are not helping us. Like, use Rust if you like it. You know, don't use it because you feel pressured about it. It's important that you can drop Rust into a C program and call what's already there and be called by what's already there.

It's important that if you have a plug-in interface where you dynamically load plug-ins, you could write one of those in Rust and be called by that plug-in interface and then translate that low-level unsafe interface to something a little safer and work from that. It's important that we don't have a runtime. So like earlier I mentioned garbage collection has overhead. Anything the language is doing behind your back that you might be surprised by, any kind of runtime like that, is something that means you can't go everywhere and that you don't want to be unpleasantly surprised by when you're in the middle of your rendering loop or in the middle of processing low latency stuff that is on the critical path to first paint or dealing with a click on the web or things like that. Right, yeah, if your program needs another program to run it. Exactly, yeah, which there's absolutely nothing wrong with that, but it means you can't go everywhere and you're not universal. Yeah, and it's interesting. You said earlier, like, you know, it's sort of you get to pick both the high-level, low-level, right?

You get the Rust and the Rust, whereas without it, a lot of people would have a sort of Python wrapper over a C core. And it sounds like with Rust, you can replace either part of that if you like. Absolutely, yeah. Like, I have seen people on the one hand have a big pile of C code, and they introduce Rust, and it gives them a taste of being able to do a higher level programming language. I've seen people, like, we actually got to a point with several of the Rust conferences when we were sitting on the program committees, we would find that we had to start turning away talks whose only point was I used Rust to speed up the hot part of my Python program. Because it's like we've seen that talk a few years running now. And that's a good thing. Like that means this is just standard practice. Like the standard accepted wisdom of my Python program is a little bit slow is find the hottest loop, the hottest part of your program and write it in Rust. and we have great things like Py03.

And increasingly, there's actually an effort to, several of the Python core developers are working on writing parts of Python itself in Rust, which is, again, one of those delightful, surprising places. Like, in the last several years, we've been hearing a lot about Rust in the Linux kernel, and we've been delighted to enable the folks who are working on that. I'm actually going to Congrehos, which is the Rust in the Linux kernel conference next week. We've also been really happy to enable the folks who are building Python interpreter code in Rust and modules for Python itself to the point where a number of years from now, when you are running Python code, some of it's going to be powered by Rust and some of it by C. And that's really a delight. So, yeah, you can replace whichever piece you want. Same way with you're on the web. You want things to go a little faster or have access to a different set of APIs. You write WebAssembly. Rust seems to be just the default language for WebAssembly. That was one of our early victories, was the idea that you don't want to have to write this in C or C++,

and if you write it in a high-level language, you'll be running a runtime on your runtime, where you can get an interpreter running inside WebAssembly, but then you're bringing the interpreter along for everything you're writing, and you're not getting a huge advantage over writing JavaScript. But with WebAssembly, you can just drop into a lower-level register and start getting certain things done to speed up your JavaScript code or to port something that exists from elsewhere. Like these days, you see so many games and tools and similar that we run on this platform, this platform, and the web. Right. And the on-the-web part is, what, mostly WebAssembly? Yeah. When you see something that's portable across 10 different places, and one of them is the web, it's going to be WebAssembly, and it'll either be some established engine that is in C or C++, or it will be something written in Rust. So I don't think we can talk about anything in programming these days

without talking about AI and agents and such. Oh, joy. Yeah, I know, I know. I apologize. Where do you think Rust fits into the new agentic programming paradigms? I think it fits in in a number of different ways. And one aspect of people doing agentic programming with AI is that they like there is a whole spectrum from people very carefully and responsibly running something and using it to check over their code or extend a part of their code or port a part of their code and reading it and understanding it or running a prompt and ending up with a whole program and just going YOLO and there a whole spectrum there And I hope to not see any of the latter in production but you know sometimes it's fun to play with. And I think that Rust fits into both of those very well, specifically that many people have talked about constraints can breed creativity,

and that's true of humans and it's true of AI. With humans, you give people interesting constraints and you will find them building the most astonishing, interesting things of like fascinating stuff with old game consoles or fascinating things with restricted, like bespoke novelty programming languages or the, you know, international obfuscated C coding contest or constraints breed creativity. and with AI you hand it a pile of constraints and all of a sudden it has a tight loop saying I have to make this a valid Rust program. It has to be properly formatted past the linter, past all of these criteria. The same thing that makes it say, well, if it compiles it's probably correct means that if it doesn't compile, the AI is not done. And so a lot of people are finding that if they're going to have the AI write a big pile of code for them, It will often reach for Rust if it's going to be something that needs low level or performance or similar.

I have often noticed that many people report independently. If you ask AI to write a program, it will tend to pick either Python or Rust as two of the most common choices, depending on whether it needs that high level or low level register. If you just ask it a very simple question and don't give it any constraints, it will often write 10 lines of Python. But if you ask it for, like, a program of various specific types, it will often give you 500 lines of Rust that, by the time it hands it to you, it definitely compiles. It's definitely warning-free. It's definitely properly formatted, all of these different things. So it steers things a little bit. So you mentioned the sort of YOLO mode. Do you think Rust makes vibe coding better and safer? So not particularly spicy hot take. I think no power on this earth makes vibe coding safe,

but everything is a spectrum in that regard. And if you're building code you just truly don't care about and you're going to throw it away in 30 minutes when it's giving you the answer that you want, there is a degree to which Rust makes it more constrained. You're not going to deal with a crash. You're not going to get, like, imagine a world without Rust where you need the AI to write some low-level program. You're going to end up with it, what, invoking a debugger inside the agent's sandbox and trying to figure out the seg fault or the race condition. If you're trying to single-shot something or run it in an agent loop, then Rust is going to get you there faster. And that is the one case I would say that vibe coding is kind of defensible, where it is you are not actually setting out to write a program. You are setting out to solve a problem, I mean. And the code is almost incidental. Like the other day I was trying an exercise of what is the AI capable of, and it's like, don't write any code, solve this problem.

and even with that instruction, it proceeded to internally write a quick Python script and run it. It was just part of its thinking register, and it obviously didn't follow the instruction, which is one of the number one problems with AI, but at the same time, the fact that it was writing a program was otherwise going to be transparent and invisible to me if I wasn't looking at how it solved the problem. It was just going to give me the answer to the question. And even if I'm asking for random web searches or random, does this product exist or things like that, it will go and write 12 lines of Python and run them because code is just a scratch register that it can use. And in that regard, it's not so much vibe coding as thinking in code. And that's pretty defensible if you're going to use it at all. Yeah. I mean, I think that is going to be, for a lot of people, one of the results of AI is that code's going to happen, there's going to have custom software, and they're not going to have to think about it.

Yeah, exactly. So you mentioned the security aspect. Obviously, that is a huge part of AI code. What do you think Rust can do there? So several answers to that question. Security has been part of Rust's DNA from the very beginning. that some of the early statistics from years ago were effectively like, this cuts 70% of security vulnerabilities. And we had, like, in one year, a number of years ago, we had three independent studies, like one from Microsoft, one from Mozilla, and I don't remember where the third one was from, that all just independently reported, yeah, it cuts, like, 70-plus percent of security vulnerabilities out completely. And that's not even counting the other types of bugs where we don't necessarily innately prevent it all the time, but because you're writing higher-level code, because you're not reinventing linked lists, because we have a broad standard library, for any number of reasons, you end up just having fewer opportunities to write bugs

because you're writing higher-level code or writing something that the type system just naturally prevents. Like, you don't write in assert that this won't happen. you write a type that says you can't possibly accept things that aren't zero. I mean, sorry, that are zero. And so part of it is Rust has been about preventing bugs at compile time for a long time, and that applies to security bugs as well. And then on top of that, when we have a massive pile of relatively inexpensive attention from AI being thrown at all sorts of security problems, whether we like it or not. Somebody's going to do it, so we might as well be doing it ourselves to figure out those bugs before they are caught and exploited. And as that bandwidth becomes cheaper and cheaper, we are going from, let's apply this to our most important code in order to secure it, to let's apply this across half the industry

and make sure that the kind of thing that previously would have required a careful security audit is now a handful of prompts and an AI that's willing to help you break security because you have to break security in order to fix it. And in that regard, I think that Rust will both help you write fewer security issues to begin with and then when you are either dealing with the 30% of security issues that are logic errors that could happen in any language, you can catch them even if they're written in Rust. And then on top of that, in the 100% of security errors you're having to deal with if you're writing in a language that doesn't catch those for you, then one thing you can do with AI is to catch that and fix that quickly. Another you can do with AI, which many people are doing now, is, hey, as long as we're pointing an AI at this code base, what if it were written in another language? And I don't necessarily think that's the right approach for a rewrite for every program, but for every one public open source library that should perhaps get a careful human port that is paying attention to the quality,

there are a hundred pieces of bespoke software that three people have ever looked at the source code that nonetheless are stuck on a user-facing web server and are in fact on a security boundary. And if the alternative was that no human was ever going to do the work to audit it and rewrite it, then an AI is certainly better than nothing. And an AI rewrite is better than nothing. Yeah, I mean, I think we've seen a few security issues in the last year or so that were resting on very little seen software. I think the XZ compression was the one. Absolutely, yeah. That one was more of a backdoor than an unintentional security problem, but there are 50 more waiting where that happened. But, like, there's something kind of hilariously amusing about carefully backdooring a piece of widely used C code.

Wryly amusing in the sense of, like, why did you add a security hole? There are 12 more already there waiting to be found. Like, if you look at the top 10 or 20 libraries, they've been audited to heck and back by humans and now by AIs. and some of them are getting close to the point where it seems unlikely that you're going to find a new security vulnerability in, you know, something as widely used as, like, the 10 most common C libraries. On the other hand, a lot of things are not the 10 most common libraries, and the long tail gets no attention, and, like, there are not enough eyeballs to make every single piece of code out there secure. Even with AI, there are not enough eyeballs, and so at least we should try to write in a secure by default mode. Honestly, one of the things that I think is fascinating as well is, I said earlier that constraints breed creativity, and that's true for AI as well.

AI has, if you've been following all of the news around AI-built proofs and similar, and all of the controversy around that as well, AI has been doing a lot of programming in Lean, the proof language, and a lot of that has similarly been, well, you can't compile it if it's not a correct proof or there was an infamous case that wasn't true where it founded bug in the lean kernel where you could prove false statements. But if you leave that aside, for the most part, if it successfully produces a program, it's a successful proof of what it was trying to prove. And I wonder the degree to which we could fix that other 30% of vulnerabilities as well where you're still going to have to write a very careful spec for your program somehow, but you could write something that is proven correct and use AI to write the proof or to verify the proof or to help you steer the proof engine Yeah I mean I talked to the creator of Lean about that about using AI to create Lean proofs

for AI-generated code. It seems like a very interesting circular way of working. It is, yeah. I just hope that we do not, in the process of doing that, lose a lot of the skills that get us there in the first place. I think that there was something outside the computing field, but in the AI field that I think computer scientists would do well to pay attention to as well. There was a great quote from Terence Tao that effectively said, we're kind of strip mining the field of interesting mathematical problems where what we will pop out with is a proof, but not all the discoveries we made along the way because people are not reverse engineering the chains of thought that the AI had to find the 27 other lemmas you had to prove along the way. And I love the quote that science is advanced less often by Eureka and more often by, huh, that's funny. And we do not necessarily stop to say, huh, that's funny.

When we're solving something with AI, we just say, here's the solution to this, you know, Millennium Challenge problem and not here's the team full of mathematicians that have been working that problem for a very long time. And I think the same is absolutely true in computer science, that if we are just paying attention to here's the problem we're going to solve, here is the code I want you to pop out with, we're not going to learn the shape of the problem, learn other discoveries along the way, and we might find ourselves strip mining the interesting problems and not having the creativity breeding grounds that sometimes involve stumbling blocks and making mistakes and going down blind alleys and otherwise saying, huh, that's interesting quite a lot. Yeah, that's something I've felt for a while is that the end result isn't always the most interesting thing in a problem. If somebody came out tomorrow with the result saying like chess is solved, it's a first

player win, like, that doesn't actually meaningfully change something about how either humans or computers play chess, but the course of trying to figure that out, of making that problem small enough to be tractable without, you know, surpassing all the world's supercomputers and crunching, would be, like, that would imply some fascinating things about how we do search or how we do game tree heuristics or how we build in-game table bases or any number of other things about how chess works and how problem solving and search works that would be much more interesting than just if I went back in time 50 years or 100 years and told them checkers is solved, it turns out to be a first player win. That doesn't tell them how to do it. It tells them a Boolean result they can't do much with. Right. So I want to get a sense of where Rust is going.

Obviously, it's a living language being developed. Would love to know, you know, what's on the roadmap that can be shared. Sure, absolutely. So one of the things I love to say about Rust is that Rust is always in the process of evolving and always in the process of continuing to meet its users' needs. I think there are two types of programming languages out there, the ones that are continuing to evolve to meet user needs and the ones that have decided to start accepting being replaced. Like things, you know, much like the old joke of things change until they can read email, programming languages evolve until they decide to be replaced. And so Rust does not desire to be replaced anytime soon. We want to build what people are looking to do with it. And at the same time, we have a kind of continuous tension where we also do not want to turn into a language with myriad dark corners that people don't know and a massive depth that can hurt people.

We like having a breadth that people can reach for and can use, but I really love the principle that I use when trying to think about proposed programming language designs of what you don't know won't hurt you, no unpleasant surprises. You'll either get pleasantly surprised or you'll just get exactly what it says on the tin, but something's not going to sneak up from the dark corners of Rust and hurt you. And so when we're designing Rust, we're trying to maintain that tension between simplicity, understandability, not being such an absurdly broad language that people desperately need to replace it with something simpler, while also still meeting users' needs. Like, we could have stopped 10 years ago and had a programming language, and we would almost certainly be replaced by now with something that does async, or with something that has better borrow checker, or with something that's faster or compiles faster, or so on. So what I'd say is we're going to keep looking at problems and we're going to keep finding the smallest change that gets us the largest number of users with the most orthogonality that feels like our favorite changes are the ones where you look at it's like, wait, it didn't always work that way.

That didn't work before is so incredibly obvious in hindsight that the fact that it didn't work is surprising once you've thought about it. So that's part of it. The other part of it is I think we want to keep leaning into that two-register system of the high-level register where it's okay to call clone and you're not too worried about overhead, where it's like, if I'm doing faster than the equivalent Python, I'm doing great. And then the low-level register of let me challenge the limits of what my hardware can do. Let me go as fast as humanly possible. Let me care about all the low-level details. We want to be careful not to have dialects of Rust where, like, one of those is completely foreign to the other. But at the same time, we want those to be two interoperable modes that you can write Rust in where maybe we give you some additional tools for making it simpler to write scripty Rust. Like we're adding mechanisms to make it easier to write scripts in Rust

and to write quick interactive programs and to do throwaway tools and similar or to build something high level where you're less worried about that. And I think we're going to continue to do that while still also giving you all that power to dip into the low level register whenever you need to, whenever your profiler says this part's actually slow and turn it into the fastest thing you could possibly build. Are you talking like a node sort of thing for Rust? Node, Python, I think there's a number of languages that we look to for inspiration. This is something I would also say, like, we've talked a lot about, oh, C this, C++, this, Python, that. Like, we don't see ourselves being in competition so much as coopetition. We very much enjoy the fact that, like, we have a great conversation going with Python folks, with C and C++ folks, with JavaScript and TypeScript folks. We had a great conversation at one of our recent programming language summits

that brought in the team that designs JavaScript to talk to them about what they're doing and exchange notes. And we've done that in the past with C++ folks. We have had a great deal of fun with it. Like I said, we're working with the team that's in Python that is adding Rust to the core of Python. we see ourselves as fitting into the ecosystem and playing nice in the ecosystem and if some other programming language is your cup of tea go ahead and write it and then under the hood you might find yourself also using some Rust or keep it in mind for when you run into that weird problem that first problem I ran into that made me say I want to use Rust was a low-level C library libgit2 actually where it's like, this is written as good as it could possibly be for a C library, but you read the documentation and it says things like, this returns something you have to free with this function. This returns something that you must not free because it's owned by this data structure.

And I remember thinking, wait, own? That sounds familiar. Ownership, borrowing, where have I seen that before? And I dug into Rust and it was just a joy to write in Rust. So like, write Python, write TypeScript, Maybe write a little less C and C++ in the current security world, but take joy in whatever language you're writing and then reach to Rust if you find that you need something that protects you, keeps you a little safer if you're on the C side of things or lets you go a little faster and have a little more low-level control if you're on the Python, TypeScript, JavaScript side of things. All right. That's a good takeaway. Take joy in your programming languages. Love it. Well, it is that time of the show again where we shout out somebody who came on to Stack Overflow, dropped some knowledge, shared some curiosity, and earned themselves a badge. Today we're shouting out the winner of a great answer badge, somebody who dropped an answer that got 100 or more points.

So congrats to Germa Vinsmoke for answering, Can I access variables from another file? If you're curious about that, we'll have the answer for you in the show notes. I'm Ryan Donovan. I host the podcast, edit the blog here at Stack Overflow. If you have questions, comments, concerns, topics to cover, please email me at podcast at stackoverflow.com. And if you want to reach out to me directly, you can find me on LinkedIn. And I'm Josh Triplett. I work on the Rust programming language and continue to take joy in doing so. And if you want to find me on the web, reach out to joshatriplett.org, and I'm happy to answer email, LinkedIn, or Fediverse conversations. And I'm available on the Rust Zulip if you want to talk about how to work on Rust or contribute to Rust. All right. Thank you for listening, everyone, and we'll talk to you next time.

Thank you.