Rust in the Kernel: The Thirty-Year Language War
Pre-Flight Metrics Card
Nuremberg, somewhere around 2006. I am at the SUSE engineering office in my Novell Pre-Sales Specialist role for ANZ and APAC, and in the room is Nat Friedman, Novell's open-source chief and the co-founder of Ximian. Friedman lived in Germany at the time. He had spent the previous three years trying to bring C# developers onto Linux through Mono, the open-source re-implementation of Microsoft's .NET that Ximian had built and that Novell had acquired along with the rest of the company in 2003. The conversation that day was about Linux strategy in the enterprise. Underneath it sat a quieter question: how do you bring younger developers, the ones who grew up on managed languages and modern toolchains, onto a platform that was still, fundamentally, a C codebase with thirty years of muscle memory wrapped around it?
That question never went away. It just changed languages.
In December 2022, Linux 6.1 shipped with initial support for writing kernel code in Rust. At the 2022 Linux Kernel Maintainers Summit, Miguel Ojeda updated the group on the status of the project. Linus Torvalds, with his usual lack of ceremony, said he intended to take the patches unless he heard a strong objection. He did not, so he took them. The first 6.1 release could load a "hello world" Rust module and not much else, but the second main language of the kernel was officially on the books.
Three and a half years later, in December 2025, Rust for Linux lead developer Miguel Ojeda posted the patch that formally concluded the experiment. The experimental flag came off. Rust is here to stay. By the time you read this, mainline Linux carries Rust drivers in the NVMe stack, in the DRM graphics subsystem, and inside the Asahi project that runs Linux on Apple Silicon. None of this would have been imaginable in 2006 over coffee in Nuremberg. All of it was implicit in the conversation.
The fight that everyone expected, and the one that actually broke out
The technical case for Rust in the kernel is straightforward and has been made for years. Roughly two-thirds of serious Linux kernel vulnerabilities trace to memory-safety bugs in C code: buffer overflows, use-after-free errors, null-pointer dereferences. Rust's compiler refuses to ship code that exhibits those classes of error. Where C asks the programmer to remember every rule, Rust asks the compiler to enforce them. That is a structural reduction in vulnerability surface area, not a marginal one.
Google's data on Android, where memory-safe code has been steadily replacing C and C++, shows the share of memory-safety vulnerabilities falling from 76 percent in 2019 to 35 percent in 2022. The substrate changes the maths.
That argument was always going to win on technical grounds. What surprised people was how badly it went on cultural ones.
In August 2024, Wedson Almeida Filho, a Microsoft engineer who had spent almost four years as a maintainer of Rust for Linux, resigned from the project. His parting message to the kernel mailing list said he was tired of what he called nontechnical nonsense. The proximate trigger was a 2024 Linux Kernel Summit session in which ext4 maintainer Ted Ts'o told Filho, with a fair amount of volume, "Here's the thing, you're not going to force all of us to learn Rust". Filho's point had been narrower than that. He wanted information from the C side so Rust bindings could statically encode file-system interface semantics and stop a category of errors at compile time. The reply he got was effectively: not my problem.
Christoph Hellwig, another senior C maintainer, had earlier compared the mixing of Rust and C in the kernel to cancer. The Rust side had its own intemperate moments. None of this looked, from outside, like a fight about engineering. It looked like a fight about identity. Whose kernel is this? Whose codebase? Whose language?
And here Linus, who has never been confused with a diplomat, did something interesting. He defended the Rust path publicly, several times, in unfussy terms. At a 2024 Open Source Summit appearance, he made the framing I think matters most for this article. He noted that one of the things he liked about the Rust side of the kernel was that "there was one maintainer who was clearly much younger" than most of the existing maintainers. He went further: certain areas of the kernel, of which Rust is the obvious one, bring in younger developers. Kernel maintainer Steven Rostedt put it more bluntly in a survey of kernel developer attitudes. Rust, in his framing, is the language younger developers want to learn. C is their dad's language.
Linus is not alone on that side. Greg Kroah-Hartman, who leads the stable kernel branch and has been Linus's most visible deputy for two decades, has been a steady advocate for the Rust effort. Dave Airlie, the long-time maintainer of the DRM graphics subsystem, has actively pushed Rust drivers into his subsystem and absorbed plenty of public friction for it. The point is not that the C generation is uniformly hostile to Rust. The loudest voices in opposition are senior, technically respected, and well placed to slow merges they do not personally want to maintain. The Rust side has senior advocates of equal standing. The question is which side is recruiting.
That is the story underneath the memory-safety headlines. The Linux kernel community is aging. Some of its senior maintainers will be in their sixties this decade, and a few will be in their seventies. Andrew Morton, who has held memory-management maintainership since before memory management was a distinct subsystem, announced in April 2026 that he intends to step back. The C generation is doing the slow handover. Rust is the door newcomers are walking through.
The C-versus-C# parallel
Watching this from the outside, the Rust debate does not remind me most of the Tanenbaum-Torvalds argument from 1992, which was about kernel architecture. It reminds me of the C-versus-C# debate that ran through the 2000s, the one Nat Friedman was inside.
C# arrived in 2002 as Microsoft's managed-code answer to Java. It was safer than C, easier to write, less prone to whole categories of error. It also asked the user to trust a runtime and to accept that the new language would slowly displace the old one in domains the old one used to own. Mono, the open-source .NET that Ximian and then Novell shipped, tried to bring that conversation into the Linux world. The reaction inside the Linux community was, to put it gently, mixed. Some of it was patent paranoia (was Microsoft setting a trap?). Some of it was tribal (this is not how we work). Some of it was a fair technical worry about runtime weight in a kernel-adjacent stack. The Mono play never reached the kernel itself. It worked in user space. It powered things people did not know it powered. But it did not become the way kernel code was written.
Rust, twenty years later, completes the move that Mono almost made. The shape of the debate is the same: this is safer, this is the future, this is not how we work. The difference is that Rust does not ask for runtime weight, does not ask kernel maintainers to accept garbage collection, and does not arrive carrying corporate political baggage from Redmond. It arrives carrying a compiler that refuses to ship the bugs that produce most of the CVEs. The case is harder to argue against on engineering grounds. So the argument moves where arguments move when the engineering case is settled: to the cultural ground, where it is really about who owns the codebase.
The supportability principle
The way I think about legacy migration, after thirty years of architecting around long-lived systems, is this. If a system is not supportable, it has to be migrated even if it still works. Working is a necessary condition, not a sufficient one. Supportability covers the people who maintain it, the toolchain that builds it, the security posture it sits in, and the realistic horizon for finding qualified hands. When any of those four legs weakens past a certain point, "it still works" stops being an argument.
By that test, kernel C still works, but it is increasingly not supportable. The vulnerability profile is dominated by a class of bugs that a memory-safe language structurally prevents. The maintainer pool is greying out of the project at a measurable rate. Younger developers do not arrive speaking C natively, and the ones who do are not being produced fast enough to replace those who leave. I have written elsewhere, in the EA Thursday series on Zero Trust modernisation, about applying the same test to legacy authentication estates. The Rust transition in the kernel is that test applied at a different layer of the stack.
New Zealand public service kernels, the ones running underneath IRD, MoH, ACC, the Ministry of Housing and Urban Development, are all C and will be C for years yet. That is a sensible local position and a global engineering bet at the same time. Rust is not coming to the public sector this year. The transition arrives in the substrate first.
The Modern Bridge
Memory safety in the kernel is a substrate-safety argument. The codebase still functions. We are migrating because the cost of not migrating compounds, and because the people who can maintain the old substrate are aging out of the labour pool.
Alignment safety in AI is the same shape of argument at a different layer. Current frontier AI systems work. They are useful. But the substrate that produces them, training methodology that does not yield interpretable weights, capability that arrives before the controls that would govern it, evaluation regimes that lag deployment by years, is generating a category of failures we cannot reliably contain. The same shape of argument I have been tracking in the Gen AI Tuesday series runs through the AI alignment debate. A working system can be unsupportable and still need migration.
In New Zealand public service technology, neither transition has arrived in production. Rust is a research curiosity. AI alignment is a governance conversation, not yet a procurement standard. Both transitions will arrive the same way the Rust transition is arriving in the kernel: driver by driver, model by model, with a small number of younger engineers carrying it in through doors the senior generation built. By the time we look up and notice we are no longer running on the old base, the migration will already be most of the way done.
The lesson Nuremberg was teaching, twenty years ago, was not about Mono. It was about how language transitions in long-lived systems actually work. They do not happen by decree. They happen because a new generation arrives, finds the door open, and walks through it.
Call to action
When was the last time you authorised a migration on supportability grounds alone, while the system in question was still functioning? What did the migration cost in budget, in calendar time, in disruption to the team carrying it? And what did the alternative, doing nothing for another year, cost the same team the year after that? Tell me the story. The ones I learn most from are the migrations that were unpopular at the start and obvious in hindsight.
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. They do not represent the views of my employer, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance. I follow the Public Service Commissioner's Code of Conduct for the Public Sector and social media guidance.
About the Author: Andreas Hamberger is a New Zealand-based enterprise architect and technology strategist. Over 30 years, he has moved from compiling kernels on a 486 to leading cloud, cyber, and AI transformation programmes across government, banking, transport, and aviation. He founded Yoper Linux, served as a technology specialist for Novell during the Linux Wars, and is the author of "Generative AI: Skynet or Heaven" and "Space Mafia." He can be reached at linux@linux.co.nz.
I use AI tools, including Sudowrite, Claude, Perplexity AI, DeepSeek AI, ChatGPT, Grok, Copilot, Openart and Gemini, as deliberate production tools, not ghostwriters. This is consistent with my position: AI amplifies human judgement; it does not replace it. The frameworks, arguments, and editorial decisions in this series are original work. AI accelerated the process. The thinking is mine.
References
[1] Corbet, Jonathan. "Rust heads into 6.1." LWN.net, 13 October 2022. https://lwn.net/Articles/908347/
[2] Sharwood, Simon. "Linux 6.1: Rust to hit mainline kernel." The Register, 9 December 2022. https://www.theregister.com/2022/12/09/linux_kernel_61_column/
[3] Prossimo (Internet Security Research Group). "Linux Kernel 2025 update: memory safety in the kernel." Prossimo memory safety programme. https://www.memorysafety.org/blog/linux-kernel-2025-update/
[4] Wikipedia contributors. "Rust for Linux." Wikipedia. https://en.wikipedia.org/wiki/Rust_for_Linux
[5] Larabel, Michael. "Rust to stay in the Linux kernel: Miguel Ojeda concludes the experiment." Phoronix, December 2025. https://www.phoronix.com/news/Rust-To-Stay-Linux-Kernel
[6] Sharwood, Simon. "Rust for Linux maintainer Wedson Almeida Filho steps down." The Register, 2 September 2024. https://www.theregister.com/2024/09/02/rust_for_linux_maintainer_steps_down/
[7] Larabel, Michael. "Rust for Linux maintainer steps down citing nontechnical nonsense." Phoronix, September 2024. https://www.phoronix.com/news/Rust-Linux-Maintainer-Step-Down
[8] Slashdot. "What do Linux kernel developers think of Rust?" Slashdot summary citing The New Stack and LKML, 8 February 2025. https://developers.slashdot.org/story/25/02/08/0455231/what-do-linux-kernel-developers-think-of-rust
[9] Coldewey, Devin. "Linus Torvalds explains why aging Linux developers are a good thing." TechCrunch, 22 September 2024. https://techcrunch.com/2024/09/22/linus-torvalds-explains-why-aging-linux-developers-are-a-good-thing/
[10] Krill, Paul. "Thirty-two years of Linux and its community." InfoWorld. https://www.infoworld.com/article/2335646/thirty-two-years-of-linux-and-its-community.html
[11] Sharwood, Simon. "Miguel de Icaza leaves Microsoft." The Register, 4 March 2022. https://www.theregister.com/2022/03/04/de_icaza_leaves_microsoft/
[12] Linux Magazine. "Ximian founder Nat Friedman leaves Novell." Linux Magazine Online News. https://www.linux-magazine.com/Online/News/Ximian-Founder-Nat-Friedman-Leaves-Novell