Rust in the Linux kernel: balance after several years

Actualizado: 2026-05-03

The decision to accept Rust in the Linux kernel was made in 2022 and landed in Linux 6.1 late 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, but 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). The February 2025 episode 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 second-class citizen at first: no rewriting existing code in Rust, only new subsystems. In 2024, the Apple GPU driver from the Asahi project — fully written in Rust — proved a real-complexity component was doable without rewriting the whole DRM subsystem. 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 showing viability in a hot kernel zone.
• 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 February 2025 episode with the public resignation of a Rust maintainer after frictions with C maintainers was symptomatic. Not purely technical but cultural: different expectations on how to review code, negotiate changes, and handle friction points.

Incomplete bindings. There are whole kernel zones with no adequate Rust interface, 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.

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. The ecosystem is mature, docs are reasonable, active mentors exist, and the bug classes that used to intimidate newcomers are covered by the compiler.

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.

Last reviewed: 2026-04-22.