At this year’s invitation-only Linux Kernel Maintainers Summit, the people who actually decide what goes into Linux settled a big question: Rust is no longer an experiment.
As kernel developer Jonathan Corbet put it, the consensus among maintainers is that Rust in the kernel is now a core part of Linux, and the “experimental” tag will be coming off. Kernel maintainer Steven Rostedt summed up the room’s reaction in three words: there was zero pushback.
That milestone caps roughly five years of sometimes-heated debate over whether a memory-safe language really belonged alongside C at the heart of the world’s most widely deployed open source operating system.
The Signs Were There
The move didn’t come out of nowhere.
At the Linux Foundation’s Open Source Summit Korea 2025, Linus Torvalds had already hinted that Rust’s status was changing. He said Rust was “becoming part of the kernel” rather than just an experiment, signaling that its role was shifting from side project to first-class citizen, especially for new drivers.
The technical case had been building for years. Back in 2019, security researchers Alex Gaynor and Geoffrey Thomas told the Linux Security Summit that about two-thirds of Linux kernel vulnerabilities stem from memory safety issues — think use-after-free bugs, buffer overflows, and other problems that C makes easy to introduce and hard to stamp out.
Rust, with its ownership model and strict compile-time checks, promised a way to write kernel-adjacent code that simply cannot hit many of those pitfalls in the first place.
A year later, at the 2020 Linux Plumbers Conference, developer Nelson Elhage helped reset expectations. Rust proponents weren’t pitching a dramatic rewrite of the existing kernel. Instead, the goal was a world where new kernel code could be written in Rust, while C remained the foundation. The main concerns were:
- How Rust would call into existing C APIs
- How to support multiple architectures cleanly
- How to keep Rust and C compatible at the ABI level
The message was clear: evolution, not revolution.
Rust for Linux: From Out-of-Tree Project to Mainline
That evolution picked up speed with Miguel Ojeda.
In 2019, Ojeda launched the Rust for Linux project, focusing on out-of-tree Rust support: bindings, abstractions, and sample drivers that could plug into the kernel without rewriting core C code. The early work proved that Rust could interoperate with the kernel’s C APIs while still enforcing memory safety guarantees.
By early 2021, Rust was increasingly visible around the Linux ecosystem. Amazon Web Services’ Bottlerocket container OS leaned on Rust for key system components, and Debian developer Sylvestre Ledru was working on packaging the Rust-based “uutils” coreutils for Linux using LLVM/Clang tooling. The language was getting closer to everyday Linux usage even before it hit mainline.
That March, Torvalds publicly moved from curiosity to cautious optimism. He described himself as being in the “wait and see” camp — interested in Rust’s promise but unwilling to force it on the project. He wasn’t pushing Rust, he said, but he was open to it if it could deliver the promised safety wins in real kernel code.
Those promises were convincing enough that, on September 20, 2021, Ojeda submitted the first major pull request to bring Rust into the mainline kernel. It included:
- Initial Rust support wired into Kbuild
- Early support for built-in Rust modules
- A new
kernelcrate with safe Rust abstractions designed by Gaynor and Thomas
The plan then — and now — was never to rewrite Linux in Rust. Instead, the project would introduce Rust selectively, in new drivers, subsystems, and helper libraries where it could deliver the most security benefit without destabilizing mature C code.
Growing Pains: Politics, Tooling, and Time
Adding a second “main” language to a project as large and conservative as the Linux kernel was never going to be smooth.
As Ojeda noted in 2022, the kernel is a massive project with many stakeholders, and bringing in Rust created both technical and management challenges. Some maintainers were enthusiastic. Others were wary of mixing programming paradigms and tooling across such a critical codebase.
In early Rust-for-Linux discussions, Video4Linux maintainer Laurent Pinchart captured the sentiment of many overworked subsystem maintainers: he simply didn’t have time to “stop everything and learn Rust anytime soon.”
That theme kept coming up. At Linux Plumbers 2024, Intel engineer Dan Williams described kernel maintainers as deeply conservative by necessity. They know C inside out, but Rust is new territory. If you don’t understand a language, it’s hard to review patches or debug tricky issues — and that’s a real problem for people who sign off on code that runs on billions of machines.
There were technical flashpoints, too. One dispute over how Rust should integrate with the kernel’s Direct Memory Access (DMA) API exposed a deeper tension: maintainers worry about increasing their long-term maintenance burden. As senior kernel developer Ted T’so pointed out, maintainers have limited time and don’t want to own fragile interactions between languages they don’t all speak fluently.
Despite all that, the Rust patch stream kept flowing. Bugs were ironed out, abstractions got more ergonomic, and the Rust-for-Linux bindings improved.
Counting the Lines: Rust Is Still Tiny, But Symbolic
Even now, Rust is a sliver of the overall kernel codebase — and that’s by design.
As of April 2025, the Linux kernel contained roughly 34 million lines of C and only about 25,000 lines of Rust. That’s barely a rounding error in terms of volume, but it’s not about raw line count. It’s about where Rust is used.
The first targets have been so-called “leaf” drivers — things like network, storage, and NVMe drivers that live at the edge of the kernel. The Rust-for-Linux bindings expose safe wrappers around existing C APIs, with Rust’s type system and borrow checker preventing entire classes of memory bugs before they ever hit runtime.
At the same time, Rust is creeping into higher-level utilities and tooling. On the distribution side, Debian developers have announced plans to make Rust a hard dependency of the foundational Advanced Package Tool (APT), starting no earlier than May 2026. That shift would mean APT — and by extension, all Debian ports — must be capable of building and shipping Rust code.
Rust is no longer a side project. It’s becoming infrastructure.
C Isn’t Going Anywhere
For all the excitement, nobody seriously expects C to disappear from the kernel.
Every maintainer interviewed for this story emphasized that C remains the bedrock of Linux. The scheduler, memory management, filesystems, and networking stacks are all written in C, and there’s no appetite for ripping out proven code just to chase a new language trend.
Instead, the emerging model looks more pragmatic:
- C stays dominant in core subsystems that are heavily tuned and deeply battle-tested.
- Rust takes on new drivers and higher-level components where memory safety risks are highest and the cost of bugs is severe but the code surface is more contained.
For would-be kernel and systems programmers, that sends a clear signal. The most valuable skill set for the next decade may be a blend: deep understanding of C and the Unix/Linux internals, plus fluency in Rust’s safety guarantees and idioms.
That combination lets developers work at the metal when needed, while steering new code into a language that can automatically prevent many of the memory bugs that have haunted C for decades.
From Experiment to Expectation
The real story of Rust in Linux isn’t that it “won” some language war. It’s that a famously conservative project — one that powers everything from smartphones and routers to supercomputers — was willing to adopt a new language once it proved its worth.
With the “experimental” label coming off at the Maintainers Summit, Rust’s future in the kernel now looks less like a gamble and more like a long-term commitment. C remains the backbone, but Rust is now officially part of the body.
For Linux, that means a gradual but meaningful shift toward safer low-level code. For developers, it marks the start of a new era where systems programming likely means knowing both languages — and understanding how they fit together inside the world’s most important open source operating system.