Rust in the Linux kernel: balance after several years
Updated: 2026-07-07
The decision to accept Rust in the Linux kernel was made in 2022 and landed in Linux 6.1[1] in mid-December that year. Back then infrastructure was minimal, bindings covered little surface, and most debate revolved around whether inclusion was desirable at all. Today, in 2026, with real drivers in production, a growing kernel subset exposed to Rust, and several public friction episodes between Rust developers and traditional maintainers, it’s time for a technical balance. Not about hype or revolution: about what works, what still hurts, and where this is reasonably heading.
Key takeaways
-
Rust-written drivers in production (Apple GPU in Asahi Linux, experimental NVMe modules) prove viability for real-complexity components.
-
Memory-bug reduction is the most tangible benefit: use-after-free, concurrency races on badly reasoned locks, simply don’t happen at the same rate.
-
The cultural cost is real: friction between Rust philosophy (rich types, abstractions) and kernel philosophy (stability, avoiding layers). A Rust maintainer’s August 2024 resignation was symptomatic.
-
Incomplete bindings remain the practical limiter: whole kernel zones without adequate Rust interface.
-
Kernel Rust is the best available entry point for new contributors from the Rust ecosystem.
Starting point and real progress
What was decided in 2022 was that Rust would enter as a second-class citizen at first: no rewriting existing code in Rust, only new subsystems. In 2024, the Apple GPU driver from the Asahi project (written in Rust since its lead developer started the port, in August 2022) proved a real-complexity component was doable without rewriting the whole DRM subsystem. By the project’s own account[2], a cube was rendering on screen within weeks of the port starting, and a full GNOME session followed soon after, without the memory races typical of a freshly written kernel driver: only a handful of logic bugs and one memory-management issue showed up. From then on, contribution pace picked up.
In 2026, relevant Rust-written drivers include:
-
The Apple GPU driver, in daily use by tens of thousands of developers on Asahi Linux Macs.
-
An experimental NVMe driver[3], maintained by Andreas Hindborg at Samsung, showing viability in a hot kernel zone: benchmarks against 6.8-6.15 put it on par with the C driver for most workloads, though C still wins by up to 6% on 512-byte blocks due to extra compute overhead.
-
Several virtualization drivers and small utilities.
Total volume remains small next to millions of kernel C lines, but trajectory is clear and produced code is robust.
What has worked well
Effective bug reduction. Memory errors plaguing kernel C (dangling pointers, use-after-free, concurrency races on badly reasoned locks) simply don’t happen in Rust at the same rate because the compiler catches them. The upfront cost of more verbose code with explicit types amortizes quickly in driver stability.
Rust’s unsafe model has worked better than some feared. C-interface zones are marked explicitly, unsafe surface is bounded, and the rest of the code leverages language memory guarantees. Reviewing a kernel Rust patch looks pretty similar to reviewing a C patch, but confidence that safe parts are effectively safe reduces cognitive load.
Lower entry barrier for new contributors. The Linux kernel always had a reputation as a hostile community. Rust doesn’t fully solve that but does lower the first technical barrier: people who never touched kernel C give it a try because the language is familiar and compiler-checked guarantees give safety against introducing catastrophic bugs in a first patch.
What still costs
Inter-process cultural friction. Linux kernel philosophy privileges backward compatibility, stability, and avoiding unneeded layers. Rust culture tends to prefer rich types, abstractions over low-level APIs, and refactors to clean up old code. These instincts clash often.
The most cited case is Wedson Almeida Filho’s public resignation[4] on August 28, 2024, after nearly four years as a Rust for Linux maintainer. He pointed to a clash with Ted Ts’o over how to type a filesystem’s semantics in Rust, and Ts’o’s reply on the kernel mailing list stuck: "here’s the thing, you’re not going to force all of us to learn Rust." Not purely technical but cultural: different expectations on how to review code, negotiate changes, and handle friction points. The episode has repeated at lower intensity in other threads since.
Incomplete bindings. There are whole kernel zones with no adequate Rust interface, as already visible in the first stable drivers, and adding one requires significant work from someone who knows kernel C and ecosystem Rust well. This work isn’t glamorous and tends to fall on a very small number of people.
Where it’s heading
The next phase, already visible in 2026, is accepting Rust for large subsystems in areas where memory safety offsets cultural cost: new filesystems, high-concurrency network drivers, experimental memory-management subsystems.
There is also recent news that reframes this whole section: Linux 7.0, released in April 2026[5], formally closes Rust’s experimental period in the kernel. The language stops being a tolerated add-on and gets first-tier support alongside C, something that had been under negotiation since the 2025 kernel maintainers summit. In practice this doesn’t change the code overnight, but it changes the conversation: the question is no longer why Rust exists in the kernel, but how far it extends.
The other vector is ecosystem-tooling maturation: adequate documentation, clearer review processes, more professionalized coexistence with maintainers. New contributions arrive better prepared, more willing to adapt style to kernel community norms.
For developers wanting to enter now, kernel Rust is probably the best available door: a mature ecosystem, reasonable docs, active mentors, and a production backend track record that gives newcomers confidence the language holds up outside the kernel too.
Conclusion
After four and a half years of Rust in the Linux kernel, the technical balance is clearly positive, the cultural balance is uncomfortable but improving, and the path forward is reasonably marked. The bet has worked enough to justify keeping it and little enough to avoid triumphalism.
The general lesson for those following from outside: integrating a new technical paradigm into a large community with its own tradition is far harder than writing the code. Code is the easy part. The hard part is negotiating culture, convincing people with founded reasons who prefer something else, and enduring the first conflict rounds until stable norms establish. Rust in Linux has gone through those rounds and survived, which is itself a strong indicator it will stay. The question is no longer whether Rust is viable in the kernel, but how far it will go in the next years.
This article is also available in Spanish.
Last reviewed: 2026-04-22.
