The Numbers Tell a Story Worth Paying Attention To
By Linux 6.12, released in late 2024, the kernel had crossed half a million lines of Rust code. That’s not a vanity metric. That’s evidence of something genuinely shifting in systems programming. The first production Rust device drivers have landed, including the NOVA NVMe subsystem work. This matters because device drivers are where kernel development lives or dies. They’re the interface between hardware and the operating system, code that runs billions of times per second on production machines.
Two years ago, skepticism made sense. Rust in the kernel felt experimental, risky, the kind of thing that would get dismissed in a code review. Today, we’re looking at actual production deployments. The Linux community didn’t suddenly become reckless. They saw data, evaluated it carefully, and made a deliberate choice to expand Rust’s role. That deserves acknowledgment.
Memory Safety Isn’t Religious War, It’s Math
Linus Torvalds made a striking observation at the 2024 Linux Plumbers Conference. Rust driver contributions showed fewer memory safety bugs in review than equivalent C drivers. That’s the kind of statement you’d normally dismiss as marketing until you realize it came from the person who has rejected more code than most engineers will write in their careers. Torvalds also acknowledged the friction honestly: the toolchain complexity remains a genuine barrier for maintainers. He didn’t pretend Rust is painless. He said it works better for certain problems.
Meanwhile, Microsoft’s Security Response Center released their 2024 report. Seventy percent of the CVEs they patch annually are memory safety issues. That’s what C’s thirty-year dominance has cost us. The kernel community didn’t invent this problem. They inherited it and have been managing it through discipline, code review, and careful architecture. Rust offers a different approach: make entire categories of bugs impossible at compile time rather than catching them in review.
Google’s Android team reported something even more striking. New Rust code in AOSP has maintained a zero percent memory safety CVE rate since introduction in Android 12. The legacy C and C++ codebase? Approximately sixty-five percent of Android security bugs stem from memory safety issues. Those aren’t small numbers. Those are the difference between a secure system and one that gets patched constantly.
The Adoption Curve Is Real, But So Is the Learning Curve
Rust’s 2024 annual survey showed that twenty-eight percent of professional Rust users cite systems programming, including OS and embedded work, as their primary use case. That’s a twelve-point jump from 2022. The momentum is there. People are learning this. Companies are investing in expertise. But it doesn’t happen without cost.
The barrier Torvalds identified around toolchain complexity is real. Maintainers need to understand Rust. They need to review Rust code. They need to debug it. The Linux community isn’t interested in hiring an army of new maintainers just to handle one language. So adoption has been deliberate, measured, and focused on areas where the value proposition is strongest. Device drivers are exactly that kind of area. They’re self-contained, they have clear interfaces, and they benefit enormously from memory safety guarantees. This isn’t theoretical work. It’s practical engineering.
You can find detailed documentation about the actual state of the project at the Rust in the Linux Kernel documentation. The information there reflects what’s actually being merged, what’s in progress, and where the bottlenecks are. It’s not marketing material. It’s the technical record.
What This Means For the Work You’re Actually Doing
If you’re building embedded systems, this changes the tools available to you. If you’re working on device drivers, you now have a language that can express hardware correctness more clearly. If you’re responsible for security in a production system, you’re watching a platform where memory safety issues are being engineered out rather than managed.
The mainstream narrative around programming languages tends toward certainty. Rust is the future, or C will never die, or whatever tribe you belong to. The actual state of systems programming is messier and more interesting. C remains deeply embedded in the kernel and will for years. Rust is growing in specific niches where the value is clear and the technical barriers can be managed. Both things are true simultaneously, and honestly, both are fine.
The lesson here isn’t about Rust or C. It’s about how real engineering works when you’re building systems at scale. You measure outcomes. You acknowledge real costs and real benefits. You move deliberately. You don’t pretend adoption is effortless, and you don’t pretend the status quo is perfect either. You just do the work and let the results speak.
The Momentum Has Weight Behind It
Half a million lines of production code isn’t a proof of concept anymore. It’s a working system. The Android memory safety numbers tell you that this approach actually works at the scale where it matters most. The continued growth of Rust adoption in systems programming tells you that engineers are choosing this tool for problems where they think it solves real problems. That’s not hype. That’s signal.
If you haven’t spent time with Rust in a systems context, now is a good time to start. The tooling is solid. The community knows what it’s doing. The kernel work provides real reference implementations. For a deeper look at how this plays out in practice, Google Security Blog: Memory safety in Android walks through specific examples of where memory safety matters and how Rust handles it differently than traditional approaches.
What gaps do you see in your own systems work? Where do you find yourself most concerned about correctness? Those are exactly the problems where a language designed around memory safety becomes genuinely valuable rather than theoretically interesting. I’m curious what you’re seeing in production. Drop a note in the comments about systems you work on and how you’re thinking about these tradeoffs.