As we close the chapter on 2025 and celebrate our second year of Rust in Production, it's time to reflect on the highlights of the 17 episodes since our last holiday special. We looked at Rust from all angles, from cloud infrastructure to embedded systems and from robotics to satellite technology. One thing that all of these stories have in common is the passion and dedication of the Rust community to build faster, safer and more reliable software. In this special episode, I want to thank all the guests who shared their experiences and insights with us, as well as our listeners who have supported the podcast throughout the year. Let's look back at some of the memorable moments from the past year and celebrate Rust's achievements. This goes beyond the case studies we've covered. It's about the Rust community as a whole and the state of the Rust ecosystem at the end of 2025. My name is Matthias Endler and you're listening to Rust in Production. Chapter 1. Crossing the Chasm One of the recurring themes in our episodes this year has been the idea of Rust crossing the chasm, from early adopters to mainstream use. This is a significant milestone for any technology. It is also very rare for a programming language to achieve this level of adoption maturity, let alone in such a short time. Rust is no longer a language for enthusiasts and early adopters only. We're seeing more and more companies and projects adopting Rust for mission-critical applications. We've heard how Microsoft mandates Rust for new components in Azure, even going so far as adding it to the Windows kernel. We've heard from Volvo using Rust inside ECUs for their vehicles, and from Prime Video using Rust to power new components in the UI layer of their streaming service. But it's not just large companies. Some of my clients managed to build impressive products with small teams using Rust. I gave a presentation at this year's CodeTalks conference in Hamburg, where I shared a few case studies. For example, how a team of just three developers built a backend service for hundreds of thousands of students in Africa who learn math and English online through low-bandwidth connections. After the service went live, they had zero downtime and were able to scale to meet the demand. The maintenance dropped to almost nothing. All they focus on now is adding new features to help students learn better. Success stories like these are why I love working with Rust. It's hard to convey just how transformative Rust can be for a project until you see it in production. I wish it was easier to demonstrate this to potential new users before they commit to using Rust for their projects. Rust is and will remain a day-two language, and the benefits become more apparent at the later stages of development. That is still a significant barrier to adoption for many teams, as they have to make a leap of faith to trust that Rust will deliver on its promises. That's why as a community, we should not stop telling the stories of Rust in production, the good and the bad, to help other teams make informed decisions on whether Rust is the right choice for them. Speaking of sharing stories, it comes as no surprise that Rust has been named Stack Overflow's most admired language every year since our 1.0 release in 2015. And what people love the most about Rust is the sense of empowerment and versatility it provides. You can write everything from the top to the bottom of your stack in it. Here's Anton Lazarev from Brave. I just feel that Rust solves so many of our problems in software development that we've run into. And it really just works everywhere from embedded to desktop to mobile to even on the web with WebAssembly. I guess my take is that you better have a really good reason not to use Rust as the go-to language for your next project. Julius Gustavsson from Volvo and Charlie Marsh from Astral both echoed this sentiment. Yeah, empowering is definitely the key word. We have been super, super happy with this project and it really shows that Rust has a bright future. The hurdles that we mentioned before when we started the project and which made it basically a non-starter for most of the ECUs that we wanted to use it, those are all coming down and or have come down already so now you have qnx support for example you have infinium tricore support there was recently an article on how to run rust together with autostar classic autostar classic is the is the common automotive software framework that most automotive software runs in and now that is becoming available for for us as well there is work being done on various different automotive platforms and components so for automotive it's, definitely a bright future. It's kind of amazing i think that i only started writing rust like a few years ago and now we've shipped i mean along with a great team like we've shipped two of these tools that are having i i think at least a huge impact on python which is like the most popular or the second most popular programming ecosystem on earth so if you think about it like rust is kind of in a lot of ways rust is kind of like powering python at least to you know if i have say about it at least rust is powering is powering python and so i don't know i've always just felt i again i never considered myself to be like a systems programmer quote unquote and most of my career i was writing typescript python i mean i did some java professionally but like i had never except for like a course in college done any c i really hadn't done any c++ and like in the span of a few years i like learned to build this kind of software so i don't know i've had just like great experiences with the community and and being welcomed into it and learning the language and i think that's should continue to be a very important part of of rust is like welcoming people in and helping them learn because the impact that we can have by building this kind of stuff is just huge even outside of rust. Finally Andrew Tinka from Scythe highlighted the confidence that Rust gives you when building software. Rust as a language sits at a very valuable point in the language design space. Really is something special in terms of the guarantees it gives, the confidence you can have when building complicated systems with it, knowing that the language has struck such a valuable trade-off between competing concerns of safety and efficiency and expressiveness. It's a technology I'm glad to use every day that I use it, and I hope that its development toward these goals continues as long as it can. And there are few, perhaps no, other languages that can make such bold claims. I certainly struggled in the past when I had to struggle multiple languages for different parts of my projects. Besides navigating different ecosystems and switching contexts, I had to deal with different build systems, package managers, and toolchains. With Rust, I can master one language and use it everywhere. It feels like this is a very common sentiment among our guests. For many, Rust became a gateway into domains that would otherwise be inaccessible, to break down the barriers to entry and make larger parts of the software stack accessible to more people. And when the time comes to integrate Rust into an existing project, it happily takes a backseat to other languages, as it doesn't require a runtime or garbage collector. You can incrementally adopt trust in your codebase one component at a time and gradually leap the benefits. This is a very appealing proposition for many teams who want to slowly and carefully oxidize their codebase without the risk of a complete rewrite. Some of my clients do exactly that to great success. Chapter 2. Fear, Uncertainty, and Doubt It is hard to build systems that must not fail. Or at least do so gracefully. And when Rust fails, it makes the headlines. Many listeners will have heard of the first CVE in Rust for Linux recently. People were up in arms about it, claiming that Rust in the Linux kernel was a mistake, because Rust has bugs too. But if you take a closer look at what actually happened, you will learn that there is no known remote code execution or privilege escalation. Yes, Rust had a bug and crashed the kernel, but it did not lead to a memory safety issue. For context, 159 other CVEs were raised the same day, in the C parts of the kernel. In comparison, Rust had one CVE in five years in an unsafe code block in the implementation of a tricky data structure. That's not perfect, but it's pretty damn close. I often hear people spread the narrative that mistakes can also happen in the Rust compiler and the standard library itself, but fail to acknowledge that a bug in the compiler is a one-time cost that affects all Rust users, and once fixed, will never happen again for anyone rebuilding with the new version of the compiler. Isn't that a massive improvement over other languages? I believe we'll have to live with the fact that there are people who will jump on any opportunity to criticize Rust. It makes for great news headlines. However, I ask you to be critical of the narrative and read past the headlines. On the other hand, when people find bugs in popular software written in C, such as Redis or Curl, the reaction is often that mistakes happen and there is no holy grail. Yes, mistakes happen in every language, but just because there is no silver bullet doesn't mean we shouldn't strive to do better. C and C++ are littered with foot guns and undefined behavior that are impossible to fix without breaking backward compatibility. If you fix a bug in Redis, that fix only applies to Redis, but not to the countless other C programs that are vulnerable to the same issue. As an example, Redis had a remote code execution vulnerability in the Lua interpreter that was enabled by default. The bug was a use-after-free combined with a null-pointer dereference. It went unnoticed for 13 years. In Rust, this code would not compile. In C, it ended in a CVE. If you can't prevent safety issues before they happen, why isn't that a big leap forward? Rust should not be rejected because part of the problem still exists after adopting it. We need to stop comparing actual security problems to an unrealistic, idealized reality where all software is bug-free. While we may never get to 100% bug-free software, we should still adopt the tooling that provably reduces the number of bugs and security vulnerabilities in our codebases today. And no, writing more unit tests or just being more careful when writing C code is not enough. The irony is that teams that adopt Rust often are more rigorous about testing, not less, because their goal of following engineering best practices is what brought them to Rust in the first place. In code reviews and when writing tests, you can focus your testing efforts on the bugs that actually matter and not undefined behavior or memory safety issues. If you put the type system to work, you have more headroom to focus on logic errors and things no compiler can catch. Another popular narrative is that replacing stable C or C++ code with Rust is a waste of time. Why replace perfectly good software that works just fine? But of course, it's not fine, and it's not stable. The myth that C code, once written and working, never changes, is simply not true. For instance, Daniel Stenberg, maintainer of Curl and former guest on this podcast, posted that he's been working on this codebase for more than two decades, and that they get one bug report every three hours. More than half of Curl's source code has been changed within the last four years. Only 1011 lines from before the year 2000 remain untouched. The reality is that programmers continuously rewrite, refactor, and introduce new bugs while doing so. Here's Adam Hendel from Tempo on the topic. There's really no such thing as finished software or a finished programming language. It's not like software is distributed in the mail where you burn stuff to a disk and mail it out, and it just runs that way forever. Software is living, breathing organisms now, so things have to be constantly fed. it. One of my personal highlights this year was when Jon Seager from Canonical came on the show to talk about their experience shipping a replacement of the GNU core utils in Rust for Ubuntu. If you've got a really interesting Rust project and you think it's a great fit for some of the work that we're doing and you want to have a conversation, then reach out. I'm open to ideas. I don't know all of the high-quality Rust projects out there. And if there are implementations of things that are very widespread that you think we should be using, then let me know. Another highlight was Google's update on their Android OS work to integrate Rust into the platform. For the first time ever, memory vulnerabilities fell below 20% of total vulnerabilities thanks to Rust. For reference, the industry norm is around 70%. But their biggest surprise was Rust's impact on software delivery. Rust changes have a four times lower rollback rate. Just imagine the eye-watering cost savings on a platform like Android with 3.9 billion active devices worldwide. The safer path is now also faster and more cost-effective. But Rust isn't the right choice for everyone. For instance, we had Richard Feldman on the podcast talking about ROC. His team moved from Rust to SIG for their compiler work, mainly because of slow Rust compile times. And it makes sense. When you're iterating rapidly on a compiler, waiting for Rust to compile can be a real productivity hit. That's a legitimate trade-off. gives you faster iteration at the cost of safety guarantees. For their use case, that made sense. The lesson isn't that Rust failed. It's that different problems need different tools. And that's okay. Let's hear it from Richard himself. Rust is such a big language with so many different features. And there's so many different competing concerns you can have in terms of like, I need to balance like making this safe and also making it well tested and well structured and easy to maintain. There's all these different things that you could be thinking about. And I think focusing on what's the end user going to get out of my program. That's the most important thing. That's got to be the North Star. And even for teams that stuck with Rust, compile times remain a common pain point. Here's Tom Hacohen from Svix and then Alexandru Ene from Prime Video. I think we got to fix the compilation time. I don't know what we can do. It's really, I think it's, it is like a bottleneck for a lot of people. It is, it is a pain and it's, it even affects, you know, like ID, like, you know, language servers and all of that, like when it's, when things are slow. so we got to fix that thing. One thing I wish we were focusing on more in the ecosystem is build speeds, like iteration times, just getting those down. I think right now we more or less accepted that Rust would be slower to compile or whatever. But I think there's examples out there in other languages where people have gotten great results. Like Zig, for example, is pushing a lot on the build speed and the iteration time. And I think we all win if we can iterate in our codes super fast, like press whatever button you're pressing to run your code. And if that's like two seconds, it's just magical. Once it gets past a certain threshold, my productivity just, I get distracted. So I would just work a lot and investing on, if I were like... If I had the power to invest in anything in the Rust community, I would say this would be a really good place to invest in iteration times and build speed to decrease them. Chapter 3. Outlook for 2026 Rust is here to stay, at least in the Linux kernel. What started as an experiment is now an official part of the project, with Google's binder driver and the Nova GPU driver being some of the most prominent examples of Rust code merged into the mainline kernel this year. As Danilo Krummlich mentioned in his episode, new contributors are excited to work on Rust code in the kernel. We now reached 200 billion downloads of crates from Crates.io this year. 200,000 crates are published and there is no sign of slowing down. The ecosystem is fantastic. The maintainers are working hard to keep up with the growth of the ecosystem and that is highly appreciated. Here's Kevin Guthrie and Edward Wong from Cloudflare. Yeah, no, like we there's a bunch of HTTP ecosystem, things that there's there's a great maintainer for all of it is like open source, the HTTP, literally HTTP crate, H2, you know, a lot of those are our core dependencies for Pingora as well. And the maintainer, Sean is incredible at what he does. so. Yeah, the thing I was going to thank the Rust community for is for being so coherent, especially around HTTP things like the hyper ecosystem, the H2, all of those things are so ubiquitous that it makes integrating with existing projects much easier. Specifically, I was working with a ClickHouse client that is an official ClickHouse client that the ClickHouse team puts out, but I needed to add a new feature for rotating MTLS certificates, which obviously their client does not support. But because they expose access to the hyper-HTTP client under the hood, it made it an easy thing to do. It's just such a good experience to come to like if you need a feature you already have the tools necessary to add functionality to tools that are published by other people in a coherent way something that you don't get in java something that you i don't know if you get in go that's not my ecosystem but as a former and recovering java programmer it's very nice the. Ecosystem though i'm sure there are gaps from time to time generally if you are looking for a particular, pattern or thing you will either find out that it is hard to do so or that someone else has already tried to at least some extent to do it and has a working very much like you know if not production ready nearly production ready implementation of it so the rust ecosystem in general has has just been kind of the amount of excitement that folks have within the community, is a great sign of promise. We're also looking forward to a year packed with Rust conferences and meetups around the world. To name the currently announced events, RustNation in London, England on February 18, Rust in Paris, France on March 27, Rustikon in Warsaw, Poland, March 19, RustWeek in Utrecht, the Netherlands, May 18, RustConf from Montreal, Canada, September 8, Oxidize in Berlin, Germany, September 14th, EuroRust in Barcelona, Spain, October 14th, and RustLab in Bologna, Italy on November 1st. Oh, and if you're bored during the holidays, why not code a little Rust? For example, I recently finished recording my Rust HTTP server course for CodeCrafters, and I will link to it in the show notes. Chapter 4. What will Rust 2026 bring us? I personally look forward to Cargo Script, which will allow you to run Rust scripts without the need for a full cargo project. This will make it easier to experiment with Rust and share small, self-contained code snippets. Simon, the editor of this podcast, has been using it heavily over the last year with the nightly releases, and I'm planning to use it for all my future blog posts. The async ecosystem still has some rough edges but i'm confident that we will see steady progress in this area better pin ergonomics could help here. I think my primary message to the rest community is just polish up async get it to be the best experience it can ever be there are some pitfalls now even though rust 2024 edition stabilized the async closures very happy about that but there are still some questions around just observability of what is happening within an async context and how do you navigate that and and just yeah and getting to getting to the bottom of issues related to to as i said the blocking issues we have and just cancellation safety and and drop safety and async drop and all these paper cuts that that just are not completely answered yes that that would be my message to really polish up that. That would make selling Rust to others much easier. That was Vegard Sandengen from KSAT. On top of that, we need even more learning resources for beginner to intermediate and advanced Rust sessions. Andrew Burkhart from 1Password agreed with me on that point in his episode when he said. Thank you to the Rust community for keeping things open, right? Like I said, there's so many books out there and the Rust book and the brown version of the Rust book is amazing with the quizzes and things. That's all great. I think we also need to continue to or increase how often we relate to people, right? Meet people where they're coming from, understanding, you know, what they do and don't know. Obviously, with someone coming from my background, that was really critical that people here did that, you know, and there's a lot of, you know, acronyms or computer science knowledge. And there's so many people in Rust that are so smart. It can be difficult. So there's a lot of that that I think we can continue to improve on. Finding paths to not just go from zero to Rust, which I think we've started on, or we have a really good path to with the Rust book, or to go from Haskell to Rust or C++ to Rust or whatever, right? I think there is a missing middle gap of how do you go from TypeScript to Rust or this or that, where it's like, I understand variables. I understand all that. So the whole beginning of Rust book feels boring and getting lost. And then we go straight into memory or, you know, async and really how async works. And there are these missing pieces sometimes. There's things like rustlings, which is incredible for like, exercise based learning. But at the end, I didn't see exercise six mesh with exercise 10. And now I understand that those are two maybe related things. And so, you know, a lot of people say, right, build stuff, that's that is the greatest way. But that's not not realistic for everyone. You know, I was working before I became a developer, I was working, you know, 50, 60 hours a week, and then, you know, coming home and trying to keep, you know, my apartment clean and all these things. And I did not have that much time left to just build things. It took me a year or more just to try and figure out, you know. React or whatever it was at the time. And if it were Rust, I was trying to learn, I had no idea how long it would have taken, you know. And so I think just finding ways to bridge those gaps and make cohesive learnings that make concepts actually make sense holistically. I think that's a really, really huge area that will help a lot of people close the gap of Rust, which will help Rust adoption you know I've seen that even here where it's like we may have something we build and go because ramping that team up on rust is just not feasible in the time frame we have well if there's better resources to get from go to rust that becomes a non-issue you know and I think we'll see rust grow the more we are open to bringing people in from more intermediate spaces into rust. Apart from that, my wishlist is pretty short. For the most part, I wish for faster compile times and more clippy lints. My personal hope is that we will see slow and steady growth. The next 10 years aren't guaranteed. Rust's success depends on maintaining the delicate balance between growth and stability. We don't need to be everywhere all at once. We don't need to be a solution to every problem. And we need to bring people along thoughtfully, not hastily. It's important to collaborate with other programming language communities, such as C++, to work on safer interoperability. Work on this has already started. There are billions of lines of C++ code representing trillions of dollars of value stored in C++ codebases. It would be naive to assume that all of this code will be rewritten in Rust anytime soon, so we need to find ways to make Rust and C++ work better together. Let's hear Victor Ciura from Microsoft. In order for Rust to succeed, C++ does not mean it has to die. So it's not a zero-sum game. It's very much about many, many years from now where we need to learn to coexist, both in terms of software interop and in terms of community interop. So I think my message would be, let's spend more time on improving these bridges and making sure the languages work well together so that we can successfully have these and as communities learn to collaborate better. Other initiatives like BorrowSanitizer, a work-in-progress LLVM instrumentation pass for detecting aliasing violations in multi-language Rust applications, also received funding. I will add a few links in the show notes for those interested in learning more. Looking ahead to 2026, the Rust project has 41 active project goals. 13 of them are designated as flagship goals. They are working on making references more ergonomic, exploring things like field projections, they are making compilation faster with parallel frontend work and build std, they are improving async Rust, but there's still a lot of work to do there. The next generation trade solver is getting closer to being production ready. They're stabilizing Polonius for better borrow checking, getting Rust for Linux into stable Rust by stabilizing the compiler and language features the kernel needs. Let's hear it from Danilo Krummrich from the Linux kernel team. When it comes to... The things that the kernel needs from the Rust project, and there are definitely things that are needed. I also want to say thank you for the great collaboration. I'm not that involved myself. I definitely want to make that clear. We have other members from the Rust for Linux team who are regularly talking to people from the Rust core team and from the Rust project in general. And there is great collaboration already ongoing. So yeah, I'm very happy to see how things go. For a full overview, check out the Rust project goals update on the Rust blog. I will link to it in the show notes. And now we wish you all happy holidays and a prosperous new year filled with safe and reliable software written in Rust. Have fun unwrapping those gifts. It's one of the few times when unwrapping is actually safe to do. Thanks to all our guests for sharing their stories, and to Simon Brüggen, friend, producer, editor, and all-around awesome human being for helping me make this podcast happen. Without Simon, there would be no Rust in production. And lastly, thanks to all of you, our listeners, for tuning in. We would never have believed that a podcast about Rust in production would find such a large and engaged audience. We always love hearing from you. Whether it's via email, social media, or in person at conferences. Greetings to all of you from around the world. We don't ask for it often, but if you enjoy the show, please consider leaving us a review on your favorite podcast platform. It really helps us reach more people and grow the Rust in production community. And if you have a friend or colleague who might enjoy the podcast, please share your favorite episode with them. Word of mouth is still the best way to spread the word about the podcast. I'd like to end with a quote from Nico Matsakis, one of the core members of the Rust team, who I had the pleasure of interviewing earlier this year at RustWeek. Yeah, be excellent to each other. I think Bill and Ted put it best, and I can't do better than that. And with that, we wrap up another year of Rust in production. See you with more stories in 2026. Rust in Production is a podcast by Corode. It is hosted by me, Matthias Endler, and produced by Simon Brüggen. For show notes, transcripts, and to learn more about how we can help your company make the most of Rust, visit corrode.dev. Thanks for listening to Rust in Production.