The Numbers Tell a Story Worth Reading
When Rust support landed in the Linux kernel with version 6.1 in late 2022, we were looking at approximately 13,000 lines of code. That was the scaffolding phase, the proof-of-concept territory where most people still treated it as an interesting experiment rather than production infrastructure. By early 2026, that number had ballooned to over 600,000 lines across drivers, filesystem abstractions, and core subsystem bindings. That’s not a gradual adoption curve. That’s the sound of something gaining serious momentum.
The acceleration tells you something important: this isn’t ideological anymore. It’s practical. Developers are reaching for Rust not because they believe in the religion of memory safety, but because they’re shipping code that works differently when you remove entire categories of bugs from the possibility space. That’s the kind of incentive that transcends mailing list arguments.
Linus Torvalds himself confirmed in a December 2025 kernel mailing list post that Rust driver contributions have been accelerating. The Nova GPU driver for NVIDIA’s open-source firmware is the highest-profile all-Rust driver effort to date. This isn’t some experimental toy driver for esoteric hardware. NVIDIA hardware exists on millions of systems. When Rust starts handling that workload end-to-end, you’re past the threshold of theoretical validation.
The CVE Evidence Is Harder to Argue With Than Any Blog Post
Here’s where the discussion stops being performative. A 2025 study from the University of Waterloo examined 150 kernel CVEs spanning 2020 through 2024. Their finding: 67 percent of those vulnerabilities fell into memory safety categories that Rust’s ownership model structurally prevents. Not mitigates. Prevents. You cannot write a use-after-free in Rust without crossing compile-time safety boundaries that explicitly force you to confront what you’re doing.
That number matters because it’s saying something concrete. If you eliminated two-thirds of kernel CVE categories tomorrow, you’d have fundamentally transformed the security profile of a system that billions of people depend on. That’s not ideology. That’s mathematics.
On the mobile side, Google Security Blog on memory safety in Android reported that memory-safe language adoption in new Android OS code reached 77 percent. Rust accounts for the majority of systems-level additions. The result? Memory safety vulnerabilities in Android dropped below 24 percent of total CVEs for the first time. When you ship code at Google’s scale and measure the empirical reduction in security incidents, you’re operating in territory where hand-waving gets replaced by incident response reports.
But Ted Ts’o’s Concerns Deserve Your Attention Too
Here’s where I want to be honest about the actual debate. Late 2025 saw veteran kernel maintainer Ted Ts’o publish a detailed technical critique that reignited conversation about Rust’s abstraction layers. His core argument: those abstractions were creating hidden performance regressions in I/O paths that standard benchmarks weren’t capturing. He wasn’t saying Rust is bad. He was saying that architectural decisions made for safety sometimes have costs that don’t show up in your microbenchmarks until you’re running real workloads at scale.
This matters because it’s the conversation that separates engineering from cheerleading. Rust’s ownership system is elegant. Memory safety is genuinely valuable. And yes, sometimes the cost of expressing certain patterns within Rust’s constraints shows up as pipeline stalls or worse cache behavior in ways that pure C code doesn’t encounter. Both things can be true simultaneously.
The healthy part of this debate is that people like Ts’o can raise these issues and the kernel maintainers take them seriously instead of dismissing them as C-language gatekeeping. That’s how you actually build robust systems at scale. You don’t suppress concerns. You measure them, quantify them, and decide whether the tradeoff is worth taking.
What This Means If You’re Starting Out
If you’re learning systems programming and wondering whether to invest in Rust, the honest answer is: yes, probably. But for specific reasons, not because of momentum.
Start by reading the Linux kernel Rust documentation. It’s extraordinarily well-written for documentation that describes how to interface with kernel subsystems. The reason to learn Rust at the systems level isn’t that it’s trendy. It’s that you get compile-time guarantees about memory safety that C makes you enforce through discipline, code review, and prayer. When you’re writing code that other people will maintain for a decade, that’s not a small thing.
But also understand: Rust isn’t magic. You can still write terrible Rust. The ownership system prevents certain categories of mistakes, but it doesn’t prevent logic errors, race conditions around mutable state, or architectural decisions that perform poorly. It raises the floor. It doesn’t guarantee you’ll never have bugs again.
The Actual Question Underneath All This
The mailing list drama, the performance critiques, the adoption curves, the CVE statistics, the heated technical disagreements over abstraction boundaries. It’s all pointing at a deeper question: what do we value in systems software?
For decades, the kernel community valued performance above almost everything else. You squeezed out clock cycles. You cached aggressively. You manually managed memory because you understood your hardware intimately and you could optimize better than any compiler. That was a coherent value system.
Rust forces you to ask whether you still want that to be true when the cost is a constant stream of memory safety vulnerabilities. Maybe for some subsystems, the answer is yes. For others, maybe not. The kernel is large enough and diverse enough that both answers can be correct in different places.
What’s genuinely interesting isn’t whether Rust wins or C wins. It’s watching a massive, decades-old codebase navigate the choice without tearing itself apart in the process. That’s the story the commit history is actually telling. If you’ve spent time in production systems, you know how rare that is.