The Numbers Tell a Story of Velocity, Not Victory

When Rust support officially merged into the Linux kernel in late 2022 with version 6.1, it arrived with roughly 13,000 lines of code. That was symbolic. A foundation. A proof of concept wrapped in enough abstraction layers to make any systems programmer’s head spin. I remember reading Linus Torvalds’ acknowledgment of the merge at the time with the kind of careful neutrality that only someone who has fought a thousand technical battles can muster. It wasn’t enthusiasm. It was pragmatism.

Three years later, that 13,000 lines has become over 600,000. The acceleration isn’t linear. It’s exponential in a way that matters. Drivers. Filesystem abstractions. Core subsystem bindings. GPU drivers, most notably NVIDIA’s Nova effort, written entirely in Rust. When Linus confirmed in December 2025 that Rust driver contributions had genuinely accelerated past the experimental phase, he wasn’t making a casual observation. He was acknowledging that something structural had shifted. The kernel maintainers had stopped treating Rust as an experiment and started treating it as infrastructure.

But here is what matters more than the raw numbers: what they represent. This is not the trajectory of a language being forced into an ecosystem where it does not belong. This is what adoption looks like when the fundamental problem Rust solves is severe enough that experienced engineers, people who have forgotten more about C than most developers will ever know, decided the integration cost was worth paying.

The Memory Safety Equation Becomes Measurable

For years, the argument for Rust in the kernel was philosophical. Memory safety matters. Undefined behavior is bad. Buffer overflows are expensive. These were true statements that made little impact on people whose livelihoods depended on shipping C code that worked. Philosophy does not move kernel maintainers. Data does.

The University of Waterloo published a study in 2025 that analyzed 150 Linux kernel CVEs from 2020 through 2024. Their finding was specific enough to matter: 67 percent of those vulnerabilities fell into memory safety categories that Rust’s ownership model structurally prevents. Not fixes. Not catches. Prevents. The distinction is crucial. A memory-safe language does not give you a security layer you can remove or disable. It gives you categories of bugs that simply cannot exist in the first place.

This landed with particular weight because it arrived alongside data from Google’s Android team. In a 2025 blog post, they reported that the proportion of new Android OS code written in memory-safe languages had reached 77 percent, with Rust accounting for the majority of systems-level additions. More concretely: memory safety vulnerabilities in Android dropped below 24 percent of total CVEs for the first time. That is not a rounding error. That is a fundamental shift in the vulnerability profile of one of the world’s most widely deployed operating systems. When you can point to those numbers and say “this is what happens when you prioritize memory safety,” the debate stops being theoretical.

Where the Real Tension Actually Lives

This is where I need to be direct with you. The kernel mailing list drama of the past two years has not been about whether Rust belongs in the kernel. That argument was largely settled by the data and by the sheer momentum of contributions. The real tension, the one that matters for anyone trying to understand where systems programming is actually headed, lives somewhere more subtle.

Ted Ts’o, one of the most respected maintainers in the kernel, posted a detailed technical critique in late 2025 that crystallized what has been whispered in private conversations and hallway discussions for months. Rust’s abstraction layers, he argued, were creating hidden performance regressions in I/O paths that benchmarks were not capturing. Not dramatic performance cliffs. Subtle degradations. The kind that accumulate across millions of operations and become apparent only when you are staring at cycle counts with the obsession of someone who has spent decades optimizing kernel code.

This is the real conversation. Not “should Rust be in the kernel” but “at what cost in cognitive load and runtime efficiency are we buying memory safety.” Both of these things matter. Memory safety prevents entire categories of bugs. But abstraction layers have costs. Trait objects carry runtime overhead. The borrow checker forces you into certain patterns, and those patterns do not always map cleanly onto the performance characteristics you need in a storage driver or a network subsystem.

The depth of this conversation is what separates the serious technical discussion from the Twitter-tier debate. Nobody is arguing that Rust is a mistake. What people like Ts’o are arguing is that Rust in the kernel is a tradeoff, not a pure upgrade, and we need to understand the tradeoffs clearly enough to know where it belongs and where it does not.

Building Abstractions That Actually Scale

If you want to understand what the kernel maintainers are actually doing right now, stop reading blog posts and read the Linux kernel Rust documentation. Not for the concepts. For the specific choices. The way they have designed the safety abstractions. The decisions about where C interop happens and where it does not. The patterns they have established for driver writers trying to write Rust code that does not pay a runtime cost for features they do not need.

What you will see is not a language being forced onto a codebase. What you will see is a community learning how to integrate a memory-safe systems language into an ecosystem where every cycle counts and every abstraction layer is contested. That is harder than either pure-C development or pure-Rust development. It requires conversations between people who think very differently about problems, and it requires genuine technical rigor to make it work.

The Nova GPU driver is instructive here. It is not a translated C driver wrapped in Rust syntax. It is written natively in Rust, from the ground up. And it works. Performance is competitive. Maintainability is better. The code is less prone to the subtle memory corruption bugs that have plagued GPU drivers for decades. But the path to getting there required the Rust community and the kernel community to have specific, detailed conversations about abstraction costs and performance requirements.

What This Actually Means for the Future

The kernel mailing list drama that has played out over the past two years is not drama in the sense of personal conflict or ego. It is the sound of a community working through a genuine technical problem. And the resolution, as best we can see it in early 2026, is neither “Rust everywhere” nor “Rust nowhere.” It is much more interesting than that.

We are watching the kernel community establish the boundary conditions for memory-safe languages in systems programming. Where Rust makes sense, they are using it. Where the abstraction overhead is too high or the problem domain does not map well onto Rust’s guarantees, they are continuing with C. The Rust abstractions are maturing. The tooling is improving. The patterns that work are being codified and shared.

This is how technology actually advances. Not through proclamations or declarations of victory. Through messy, detailed, sometimes contentious technical work. Through people like Ted Ts’o pushing back on performance regressions and people like Linus acknowledging when a new approach is producing measurable value. Through data like Google’s Android report and the University of Waterloo CVE analysis that let us move beyond ideology into engineering judgment.

If you have been following this debate from a distance, uncertain whether to take it seriously or dismiss it as language wars, look at the actual numbers and the actual code. The memory safety story matters. The performance questions matter. Neither one is settled, and that is precisely why the conversation is worth having. What questions do you see emerging from your own systems work that might shift with a memory-safe language in the mix?