Hey everyone, welcome back to My Weird Prompts. I am Corn, and I am sitting here in our Jerusalem home with my brother. It is a beautiful evening here, and we have a topic today that is honestly one of the most consequential shifts in the history of computing, even if it sounds a bit niche at first glance.
Herman Poppleberry, at your service. It is good to be back behind the microphone, especially for this one. This is a topic that has been simmering for years, but as of March twenty twenty six, we are finally seeing the architecture of the digital world fundamentally change. We are talking about the end of an era and the beginning of a very complicated, very heated new chapter.
Yeah, our housemate Daniel sent us a voice note earlier today that really set the gears in motion. He was asking about something that has been a massive point of contention in the software world for a few years now, but it feels like we are finally seeing the long term fallout and the real world benefits. He was asking about Rust in the Linux kernel. And I have to say, Daniel has a knack for picking topics that are right at the intersection of extreme technicality and high stakes drama.
It really is high drama. When you think about the Linux kernel, you are thinking about the most important piece of software on the planet. It runs the servers that power the internet, it runs the phones in our pockets, it runs the cloud, and it runs the embedded systems in everything from cars to medical devices. For over thirty years, that foundation has been built almost exclusively on one language, which is C.
And for a long time, that was seen as an immutable law of nature. C was the kernel, and the kernel was C. But then came the shift. I think the moment people realized this was actually happening was when Linus Torvalds, the creator of Linux and a man not exactly known for suffering fools or jumping on hype trains, gave it his seal of approval. He went from being a skeptic to saying that Rust in the kernel was not just a possibility, but a necessity.
C has been the undisputed king of systems programming since the early nineteen nineties. It is the language Linus used to write the very first version of Linux in nineteen ninety one. But recently, we have seen this newcomer, Rust, break into that inner sanctum. It was officially merged into the mainline kernel in version six point one, back in December of twenty twenty two. It was the first time in the history of the project that a second high level language was officially sanctioned for use in the kernel.
And that did not happen without a fight. There was an absolute uproar on the mailing lists. People were calling it a fad, people were worried about complexity, and some were just plain offended that the purity of the C codebase was being compromised. It felt like a religious war in some corners of the internet.
It was a clash of civilizations, honestly. You have the old guard who have spent decades mastering the art of manual memory management in C, and then you have this new generation of engineers coming in with a language that basically tells the compiler to do the babysitting for you. But before we get into the drama, we should probably answer Daniel's first question: what actually is Rust?
Right. To a lot of people, it just sounds like another programming language in a sea of options. But Rust represents a fundamental shift in how we think about computer memory. It was originally a side project at Mozilla, designed to help build a better web browser engine. The big breakthrough of Rust is something called the borrow checker.
The borrow checker is the heart of the machine. To understand it, you have to understand how C works. In C, the programmer is God. You have total control over the hardware. When you need memory to store data, you ask the system for a block of bytes using a command like malloc. When you are done with it, you have to remember to give it back using free. If you forget, the memory stays occupied forever, which is a memory leak. If you try to use it after you have already freed it, you get a use after free bug. If you try to write more data than the block can hold, you get a buffer overflow.
I like to use the library book analogy for this. In C, anyone can grab a book from the shelf. There is no librarian. You can take the book home, you can give it to a friend, you can tear out a page, and three different people might think they own the same copy of the book at the same time. Eventually, someone tries to read a page that is not there, or two people try to write on the same page at once, and the whole library collapses.
That is exactly it. In Rust, the compiler is like a very strict, very fast librarian. This librarian enforces a set of rules about ownership. Only one person can own a piece of data at a time. If you want to give it to someone else, you have to move it to them, and then you cannot use it anymore. Or, you can borrow it. But if you borrow it, the librarian makes sure that the original owner does not disappear while you are still holding the book. And most importantly, you can have many people reading the book at once, but if someone wants to write in it, they have to be the only one holding it. No one else can even be looking at it while it is being changed.
And the key thing here, which is what makes it viable for the Linux kernel, is that all of this checking happens at compile time. It is not like Java or Python or Go where there is a garbage collector running in the background while the program is active, cleaning up the mess. A garbage collector is like a janitor who follows you around and picks up your trash, but that janitor takes up space and slows you down.
Right. That is the zero cost abstraction part of the Rust pitch. You get the safety of a high level language, but you do not pay the performance penalty of a runtime manager. When your Rust code finally turns into a binary file, all those safety checks have already been cleared. The final machine code is just as fast as C, but it is mathematically proven to be free of those common memory bugs.
So today we are going to peel back the layers on this. We want to look at why this was technically necessary, because it was not just about people wanting to use a shiny new toy. There are fundamental safety issues with C that have become a national security concern at this point.
That is not an exaggeration. We will look at the memory safety crisis, how Rust actually works under the hood to solve it, and then we will dive into that cultural friction Daniel mentioned. Why did this cause such a massive stir in the community?
I think a good place to start, Herman, is just the sheer weight of the history here. We actually touched on the evolution of operating systems back in episode seven hundred twenty nine, where we talked about the DNA of modern systems. C is that DNA. Why has it been so hard to move away from it?
Well, C is incredibly close to the metal. When you write C, you are basically writing a slightly more readable version of machine instructions. It gives the programmer total control over the hardware. For a kernel, which has to be fast and lean, that control is intoxicating. But that control is a double edged sword. Humans are notoriously bad at being perfect, and in a codebase as large as the Linux kernel, which has over thirty million lines of code, perfection is impossible.
And we have some pretty staggering numbers on this. I was looking at reports from Microsoft and Google, and they both found that roughly seventy percent of all their security vulnerabilities across their entire product lines were related to these memory safety issues. Seventy percent. Think about that. For decades, we have been trying to fix security by building better firewalls or better encryption, but seven out of ten holes in the bucket are caused by the fact that we are using a language that lets us make these basic mistakes.
Even the Cybersecurity and Infrastructure Security Agency, or CISA, in the United States has issued reports specifically urging developers to move away from C and C plus plus for memory safe languages like Rust. When the government starts weighing in on your choice of programming language, you know the situation is dire.
So let us get into the technical deep dive. How does Rust actually talk to hardware if it is being so protective? Because a kernel has to do things that are inherently dangerous. It has to talk to memory addresses that represent a graphics card or a network controller.
This is where the unsafe keyword comes in. This is a brilliant piece of language design. Rust allows you to create a block of code marked as unsafe. Inside that block, you can do the dangerous things that C does. You can dereference raw pointers and talk directly to hardware. But the goal is to keep those blocks as tiny as possible. You wrap that unsafe code in a safe abstraction.
So it is like having a high voltage room in a building. The room is dangerous, but it is clearly marked, and only people with the right gear go in. The rest of the building is perfectly safe because the dangerous stuff is contained.
In C, the whole building is high voltage. In Rust, if the system crashes, you know exactly where to look. It is almost certainly in one of those small unsafe blocks, rather than being a needle in a thirty million line haystack. This is especially important for drivers. Drivers are the things that let the kernel talk to your hardware, and they are historically the buggiest part of the kernel.
I remember reading about the Asahi Linux project. They are the team porting Linux to Apple Silicon, the M one and M two chips. They wrote their entire graphics driver in Rust. That was a huge proof of concept.
It was a massive milestone. The lead developer, Lina, mentioned that by using Rust, she was able to catch complex concurrency bugs, what we call data races, at compile time. In C, those bugs would have manifested as random, impossible to find crashes that only happen once every thousand hours. Rust caught them before the code even ran.
But let us talk about the performance overhead. If the compiler is doing all this work, does the code run slower?
In almost all cases, no. Because the checks happen during compilation, the actual machine code that ends up on your processor is extremely lean. In some cases, Rust can even be faster than C because the compiler has more information about how memory is being used, which allows it to perform optimizations that a C compiler would be too afraid to try.
Okay, so the technical case is ironclad. Seventy percent of bugs eliminated, performance is parity or better, and it makes drivers easier to write. So why the uproar? Why were the mailing lists on fire?
Because software engineering is not just about code; it is about people and culture. And the Linux kernel culture is... well, it is legendary for being abrasive. You have maintainers who have been doing this for thirty years. They have developed a sort of muscle memory for C. To them, Rust feels like an insult to their craft.
I imagine it is like being a master carpenter who has used a hand saw for forty years, and suddenly someone tells you that you have to use a laser cutter because it is safer. You might feel like your skill is being devalued.
That is a huge part of it. There is a steep learning curve to Rust. The borrow checker is famous for being frustrating when you first start. It feels like the compiler is screaming at you. For a senior kernel dev, they feel like they know how to write safe C. They have the mental discipline. They argue that if you just write better C and use better testing tools, you do not need a whole new language.
But we know that is not true. Even the best C programmers make these mistakes. We have seen it in the most heavily audited code on earth.
Right, but the friction was also about the build system. This is the complexity tax we mentioned in episode ten hundred thirty six. Linux is built using a toolchain that is very stable. Adding Rust means you now have to have the Rust compiler, called rustc, and the Rust package manager, called Cargo, integrated into that build process. This creates a massive headache for people who have to maintain the kernel across dozens of different hardware architectures.
And then there is the dependency issue. The Rust ecosystem moves very fast. The compiler gets updated every six weeks. The Linux kernel, on the other hand, is built on the idea of long term stability. There were huge arguments about which version of the Rust compiler should be supported. If I write a driver today, will it still compile in ten years?
That was a major point of contention on the Linux Kernel Mailing List, or LKML. I remember some of those threads. They were brutal. There was one specific argument about the size of the binaries. Some developers were worried that Rust would add bloat to the kernel, making it too large for small embedded devices.
Was that true?
Not really. You can tune Rust to be very small, but the perception of bloat was there. And then you have the human cost. In twenty twenty four, we saw a really high profile moment where Wedson Almeida Filho, one of the main maintainers of the Rust for Linux project, actually resigned. He cited non technical nonsense as the reason. He basically said that the constant pushback and the cultural friction from the C maintainers made the work unsustainable.
That is heartbreaking, honestly. You have someone trying to improve the security of the entire world, and they get bullied out of the project by people who are afraid of change.
It highlights the generational shift. You have younger developers who see C as a relic, a dangerous tool from a less civilized age. And you have the old guard who see Rust as a overcomplicated mess of modern abstractions. There was an argument that Rust code is actually less readable because it uses so many macros and traits. In C, you can see exactly what is happening to every bit. In Rust, a lot of that is hidden.
It is the classic struggle between explicitness and safety. C is explicit about everything, including the mistakes. Rust is safe by default, but it achieves that safety through a lot of complex machinery under the hood.
And we should talk about the silo effect. If a bug happens at the boundary between a C part of the kernel and a Rust part, who is responsible for fixing it? The C maintainers do not want to learn Rust, and the Rust developers might not have thirty years of experience with the legacy C code. It creates these two camps inside the same project.
I think that is why the incremental adoption strategy is so important. Nobody is trying to rewrite the whole kernel. That would be impossible. It is over thirty million lines of code. If you rewrote one percent of the kernel every year, it would take a century.
The plan is to use Rust for new things, especially drivers and new subsystems. It is about stopping the bleeding. If we can ensure that new code is memory safe, we can slowly improve the overall security posture of the kernel without breaking everything that already works.
It reminds me of our talk in episode ten hundred thirty three about how programming languages are becoming more opinionated. We are moving away from the era where the language was just a tool and toward an era where the language is a partner.
And that is a hard transition for people who have spent their whole lives being the sole authority on their code. It feels like a loss of agency. But when you look at the results, it is hard to argue with. Beyond the Asahi project, we are seeing Rust being used for NVMe drivers and even parts of the file system code.
So, for the listeners who are hearing all this and wondering what the practical takeaway is, what does this mean for the future of software? Is C going away?
No, C is not going anywhere for a long time. There are billions of lines of C code that work just fine. But the rules of engagement have changed. If you are starting a new project today that needs to be secure and fast, Rust is increasingly the default choice. It is about choosing the right tool for the job. C is like a scalpel. It is incredibly sharp and precise, but if you slip, you can do a lot of damage. Rust is like a surgical robot. It is more complex to set up, but it has built in safeguards that prevent those slips from happening in the first place.
That is a great analogy. And for anyone listening who wants to get their hands dirty, the Rust for Linux project has some amazing documentation. You can actually see how they are mapping C concepts to Rust concepts. It is a masterclass in systems engineering.
It really is. And I think it is also a lesson in community management. The Linux community is famously rough, but the fact that they were able to have this massive, heated debate and still come out the other side with a working integration is a testament to the strength of open source.
And that consensus is what keeps the world running. If Linux had stayed stuck in its ways and refused to adapt, we would be facing an even bigger security crisis than we already are. The geopolitical implications are huge too. When you have state sponsored actors looking for any tiny hole in the infrastructure of their rivals, memory safety becomes a matter of national defense.
That is why the White House issued that report in twenty twenty four recommending memory safe languages. It is unprecedented to see the government weigh in on which programming language people should use. But it makes sense. If the foundation of your digital economy is built on a language that is inherently prone to a certain class of bugs, you have a systemic risk. Rust is the most viable path we have right now to mitigate that risk without sacrificing the performance we need.
So, looking forward, what do you think the next ten years look like for the kernel? Do we see a fifty fifty split between C and Rust?
I think we will see a slow but steady migration. New subsystems will probably be written in Rust by default. We might see some older, high risk subsystems get rewritten if they are small enough. But the core of the kernel, the scheduler, the memory manager, those will likely stay in C for our lifetimes, just because the risk of changing them is so high. It is like replacing the engine of a plane while it is flying. You only touch the parts you absolutely have to.
But the fact that we now have the option to use a better tool for the wings or the landing gear is a huge win. It makes the whole plane safer.
And it is not just Linux. Microsoft is rewriting parts of the Windows kernel in Rust. Google is using it heavily in Android. The momentum is clearly shifting. The era of manual memory management as the only way to do systems programming is over.
I want to circle back to something Daniel mentioned in his prompt, which was the idea of the uproar. I think it is important for people to realize that tension in a community is not always a bad thing. Sometimes that friction is what polishes the final product.
That is very true. If the C maintainers had not pushed back so hard, the Rust integration might have been sloppy. It might have introduced new kinds of complexity that we would regret later. Because they were skeptical, the people building Rust for Linux had to be twice as good. They had to prove every single design decision. It forced them to be rigorous. And in a kernel, rigor is everything.
It really is. I am actually feeling quite optimistic about it. Seeing these two communities, which are so different in their philosophies, find a way to work together is inspiring. It shows that even in a very polarized world, technical excellence can be a common ground.
It is a nice thought to end on. Herman, I think we have given Daniel a lot to chew on.
I hope so. It was a great prompt. It really forced us to look at the intersection of code and culture. Before we wrap up, I just want to say to our listeners, if you are enjoying these deep dives, please do leave us a review on your favorite podcast app or on Spotify. We have been doing this for over a thousand episodes now, and your feedback is still the thing that keeps us going.
It really does. It helps other people find the show, and we love hearing what you think.
And if you want to check out our archives or get in touch with us, you can find everything at our website, myweirdprompts dot com. We have the full RSS feed there, and a contact form if you want to send us a prompt of your own.
Maybe you can be the next Daniel and send us down a rabbit hole.
Well, this has been My Weird Prompts. I am Corn Poppleberry.
And I am Herman Poppleberry.
Thanks for listening, everyone. We will see you in the next one.
Take care.
You know Herman, I was thinking about that borrow checker analogy again. If the compiler is the librarian, I feel like I would be the guy who keeps trying to sneak a coffee into the reading room.
Oh, you absolutely would be. And the Rust compiler would just slam the book shut and tell you to leave before you even got through the door.
It is for my own good, I suppose.
It really is. That is the thing about safety. It feels like a nuisance until it saves your life. Or in this case, saves your server from a massive data breach.
Fair point. I will take the strict librarian over a crashed kernel any day.
Me too. Alright, let us go see what Daniel is cooking for dinner. I think it is his turn.
I hope it is not as complex as a Rust build system.
If it is, we might be eating at midnight.
Actually, speaking of complexity, I wanted to touch on one more thing before we totally sign off. We mentioned the build system friction, but I think it is worth noting that this is not just a Linux problem. Any large scale legacy system is facing this right now.
Oh, for sure. You look at the banking systems running on COBOL, or the air traffic control systems. The transition from one era of programming to another is always messy. But the Linux kernel is the most visible example because it is so central to everything.
It is the bellwether. If Linux can successfully integrate Rust, then it proves that it can be done anywhere. It sets the blueprint for how you modernize a massive, mission critical codebase without breaking it.
And that blueprint is basically what we talked about. You do not do a total rewrite. You build bridges. You create safe interfaces between the old and the new. You allow the two systems to coexist for a decade or more.
It is a very conservative approach to progress, in the best sense of the word. It is about preserving what works while carefully adding what is needed.
It is about being pragmatic. And that is why Linux has survived for thirty five years while so many other operating systems have disappeared. It knows how to evolve without losing its soul.
That is a perfect way to put it. The soul of Linux is that pragmatism. Whether it is written in C or Rust or some language we have not even invented yet, as long as it stays pragmatic and open to debate, it will be fine.
I agree. It is the process that matters more than the syntax.
Well, now I am really hungry. Let us go.
Lead the way, Corn.
Thanks again for listening, everyone. This has been My Weird Prompts, episode ten hundred fifty nine. We will be back soon with more explorations into the weird and wonderful world of technology and beyond.
See you then.
One last thing, Herman. Do you think we should do an episode on the actual history of the C language itself? Like, going all the way back to Dennis Ritchie and the original Unix days?
I would love that. There is so much lore there that people have forgotten. The way C was designed to fit into the memory constraints of those old PDP computers is fascinating.
Let us put it on the list. I think the listeners would enjoy that context, especially after today's talk.
Definitely. It would be a great companion piece to episode seven hundred twenty nine.
Alright, now we are really leaving. Bye everyone.
Goodbye.
You know, I just realized I did not mention that I am a sloth.
And I did not mention I am a donkey.
Probably for the best. Keeps the focus on the code.
Though a donkey and a sloth arguing about Rust is a pretty good mental image.
Maybe for the next episode.
Maybe.
Alright, for real this time. Bye.
Bye.
So, thinking about the future of the kernel again, do you think we will ever see a day where the C code is actually the minority?
That is a long way off. If you think about the volume of code we are talking about, it would take decades of Rust development to even reach parity. But in terms of active development? Like, where the most new commits are happening? We might see that shift in the next five to seven years.
That would be a massive milestone. It would basically mark the end of the C era for new systems development.
It would. And it is already happening in other places. If you look at new projects in the cloud native space, almost none of them are being started in C or C plus plus. It is all Go or Rust.
It is a shift in the gravity of the whole industry. C is becoming the Latin of the computer world. It is the foundation that everything is built on, and it is beautiful and powerful, but fewer and fewer people are speaking it as their primary language.
That is a perfect metaphor. We still study Latin to understand how languages work, but we do not use it to write new laws or novels. C will always be there, under the hood, but the interface to the world will be something else.
It is a bit bittersweet, is it not? There is a certain rugged beauty to a perfectly written C program.
There is. It is like a handmade watch. Every gear and spring is visible and doing exactly one thing. Rust is more like a modern digital watch. It is more accurate, more durable, and has more features, but you lose that direct connection to the mechanical soul of the thing.
I think that is what the maintainers were mourning. That loss of the mechanical soul.
I think you are right. But at the end of the day, when you are running a hospital or a power grid, you want the digital watch. You want the thing that is not going to stop ticking because a tiny speck of dust got into the gears.
Hard to argue with that. Safety first.
Safety first. Always.
Alright, I am actually walking out the door now.
Me too. Catch you in a bit.
This has been My Weird Prompts. Check out myweirdprompts dot com for more.
See ya.
