| Layer | What Rust Brings | Where C Still Wins |
|---|---|---|
| Kernel drivers | Compile-time safety on the most security-sensitive code in the stack | Complete API coverage and decades of existing driver code |
| System daemons | Fewer shipped CVEs; real production examples like sudo-rs and stratisd | Familiar ecosystem for existing teams |
| CLI & userspace tools | Lowest-risk entry point; already adopted by Ubuntu | Massive catalog of existing tools; well understood by ops teams |
| Hypervisors & VMMs | Proven safety at scale with projects like Firecracker and Cloud Hypervisor | Legacy virtualization codebases are not transitioning |
| Embedded Linux | Certified toolchains available for safety-critical applications | Better support for obscure architectures and legacy silicon |
Quick Summary
Rust just became permanent in the Linux kernel, and every engineering lead is getting the same question from their team: Do we start using it, and where? Having shipped kernel drivers and embedded Linux work in Rust across client engagements, we’re laying out where Rust is already running, how it compares to C across the stack, how to pick a first project without wrecking your roadmap, and the traps we’ve watched teams fall into on real kernel work.
Table of Contents
Introduction
In December 2025, at the Linux Kernel Maintainers Summit in Tokyo, the kernel team made a decision that closed a five-year debate. Rust is no longer experimental in the Linux kernel. It is now a permanent core language alongside C. For engineering leaders who have been tracking Rust for Linux Development from a distance, that decision changes the nature of the conversation.
The question is no longer whether Rust belongs in Linux work. That has been answered, and answered in production, by some of the largest engineering organizations in the world. The question now is where it fits in your own stack, what it costs to adopt, and how to get started without disrupting what is already shipping.
This guide walks through that decision. We’ll cover where Rust for Linux Development is already running at scale, what it actually changes for your team, how to pick your first project, and the mistakes that slow teams down. It’s written for CTOs, engineering leads, and technology decision-makers.
Where Rust for Linux Development Already Runs in Production
The fastest way to understand how serious this shift is: look at where Rust is already doing the work. Not in proof-of-concept demos. In production, at scale, handling workloads that enterprises and consumers depend on every day.
The Linux Kernel Itself
The kernel contains roughly 34 million lines of C and about 25,000 lines of Rust as of April 2025. The Rust footprint is small today, but it is growing fastest in new drivers, which is exactly where memory safety matters most. Android 16 ships a Rust-based memory allocator on the Linux 6.12 kernel, which means millions of phones in your pocket are already running Rust kernel code. Linux maintainer Greg Kroah-Hartman has publicly said that Rust drivers have been measurably safer than their C equivalents.
Ubuntu Replacing Core Utilities
Canonical made a call that would have been unthinkable a few years ago. Ubuntu 25.10 ships Rust-based coreutils as the default, replacing the GNU versions of commands like ls, cp, and mv that have been the foundation of every Linux system for decades. The plan is to carry this into Ubuntu 26.04 LTS if the transition holds. Debian has also made Rust a required dependency in its APT package manager. The most foundational layer of Linux userspace is being rewritten, and Rust is the language doing the rewriting.
Cloud Infrastructure at Planetary Scale
AWS Firecracker is the Virtual Machine Monitor behind AWS Lambda and Fargate. Every Lambda function execution, and there are trillions every month, runs inside a Firecracker microVM. Firecracker is 83,000 lines of Rust. Amazon chose Rust specifically because when you are running arbitrary customer code in shared infrastructure, a memory safety bug in the isolation layer could allow one customer to access another’s data. That risk was unacceptable. Rust made it possible to build a VMM with a small enough attack surface that AWS was willing to bet one of its biggest services on it.
- Cloudflare uses Rust for performance-critical network processing where low-latency matters.
- Microsoft uses Rust in Azure and contributes Hyper-V drivers to the Linux kernel.
- Meta is rewriting parts of its mobile messaging infrastructure in Rust.
When hyperscalers make language choices, they make them because the math works at their scale. Rust for Linux Development is where that math is landing.
Automotive and Embedded
Volvo’s XC90 and Polestar 3 ship Rust-based software in their vehicle control units. Toyota’s mobility subsidiary joined the Safety-Critical Rust Consortium in 2024. Bosch’s ETAS division announced Rust adoption for future automotive software later that same year. ISO 26262-certified Rust compilers are now available, which means Rust can be used in automotive safety-critical code with full regulatory compliance. Espressif, maker of the ESP32 microcontrollers in countless IoT devices, supports Rust officially, alongside the C++ ecosystem that has dominated embedded systems for decades. ARM upgraded to Platinum membership in the Rust Foundation in September 2025.
Cars, factory equipment, and smart devices increasingly run Rust. The embedded world, which was the last stronghold of C-only thinking, has moved. For teams evaluating Rust for Linux Development in embedded contexts, the ecosystem is no longer a question mark.
What Rust Actually Changes for Your Linux Development Work
Before we get to the practical side, it helps to understand what Rust for Linux Development actually delivers, and what it does not.
The reason Rust for Linux Development exists, at its core, is one statistic. About 67% of Linux kernel CVEs between 2020 and 2024 were memory safety bugs. Microsoft has reported roughly the same number across its own security patches, and the pattern holds across C++ codebases in security-critical systems too. Google reports it for Chrome. These are not unusual organizations making unusual mistakes. They are the largest engineering teams on the planet, and they keep shipping memory bugs because C does not prevent them from being written.
Rust is a different kind of tool. The compiler refuses to build code that contains the most common memory errors. Use-after-free, buffer overflows, and data races between threads cannot compile in safe Rust. It is not that they are harder to introduce. They literally cannot exist in the safe subset of the language. For security-sensitive Linux work, kernel drivers, network processing, and virtualization layers, this matters.
This is not theoretical. The White House Office of the National Cyber Director issued guidance in February 2024 explicitly urging the software industry to move toward memory-safe languages, naming Rust. CISA and NSA have issued similar recommendations. For regulated industries, for government contractors, for any organization where security audits matter, the pressure to move new system code to Rust is building year over year.
What Rust does not do is equally important. It does not fix logic bugs. It does not prevent protocol errors. It does not make code bug-free. What it does is eliminate one specific, very expensive, very common class of bugs. That is the entire pitch, and it is enough of a pitch for some of the largest engineering organizations in the world to bet on it.
Rust vs C at Each Layer of Linux Development
Here’s how the trade-offs land layer by layer, so you can think about where Rust fits in your own stack:
A Bacancy Expert Note: Rust wins on safety and attracts modern systems and developers. C wins on maturity, coverage of obscure architectures, and the existing codebase you already have. For most teams, the practical answer is a mix. Rust for new code, C where it is already working. (If you’re also weighing Rust against Go for systems work, we break that down in our Golang vs Rust comparison.)
Inside a Bacancy Rust for Linux Development Engagement: Shipping a First Driver
The engagements we get called into look similar. An enterprise team has read the same headlines everyone else has. Their security organization has flagged memory safety in an annual review. Leadership has decided Rust is the right direction for new Linux work. What they do not have is a way to get there without pulling their strongest kernel engineers off revenue-critical projects for a quarter of unproductive learning.
Here is the pattern we run with clients in this position.
The starting point. A pure C and C++ shop building Linux-based appliances or infrastructure, with strong kernel engineers and a new piece of hardware on the roadmap that needs a driver written from scratch. That driver is the greenfield opportunity.
How do we scope it? Three outcomes agreed up front. Ship the new driver in Rust through internal review. Bring three to five senior C engineers to a level where they can maintain the Rust code without us. Produce an internal playbook so the second Rust project does not repeat the first one’s learning curve.
How we structure the work. Two Bacancy Rust engineers embed with the client team for a quarter. Weeks one to six are paired work on the unsafe FFI boundary, with our engineers writing bindings and theirs writing safe wrappers. By week seven, roles invert. Their engineers own the core driver logic. We move to review and unblock. By quarter end, the driver is merged and the client team runs the next one without us.
How to Start Your First Rust-Based Linux Development Project
The teams that have successfully adopted Rust follow a consistent pattern. The teams that struggle all make the same mistake, which is trying to rewrite working C code. Here’s what works.
Step 1: Pick a New Component, Not a Rewrite
The kernel’s official policy says it clearly: Rust is for new code, C stays where it is. Your internal policy should say the same thing. Start with something you were going to build anyway. A new driver for new hardware. A new internal tool. A new service that did not exist yesterday. Greenfield work is where your team can learn Rust without fighting legacy integration issues on the first project.
This is also where the risk is lowest. If the first Rust project runs into trouble, nothing in production is affected. You learn, you adjust, you try again. That is not true if you start by rewriting a component that is already serving customers.
Step 2: Invest in Training Before You Ship
Rust is not hard to read. Most C developers can understand Rust code within a week. Writing it is another matter. The borrow checker, which is the compiler feature that enforces the safety guarantees, is where every experienced C developer hits resistance. Budget two to four weeks of focused training per developer for basic fluency. Budget a full quarter before the team is productive on kernel or driver work.
There are good training options. The Rust Foundation maintains free learning resources. Ferrous Systems, one of the companies that built ISO 26262-certified Rust compilers, offers corporate training for safety-critical teams. The worst thing you can do is tell a team to learn Rust on their own while also shipping features. That produces frustrated developers and bad Rust code. Give the team real time to learn.
One thing worth calling out: if nobody on your team has shipped Rust in production before, training by itself is not going to get the first driver out the door on time. A cleaner move is to hire Rust developers who can sit with your C engineers, write production code alongside them, and answer borrow checker questions as they come up. Your seniors pick up Rust on the actual problem, and the project keeps moving while they do.
Step 3: Pair Rust Developers With C Subsystem Owners
The friction in Rust for Linux Development almost never comes from writing Rust. It comes from the boundary where Rust meets existing C code. Kernel APIs, hardware interfaces, and system call conventions were all designed for C. Translating them into safe Rust requires understanding both sides. Pair a developer learning Rust with someone who already knows the subsystem in C. The two of them together will solve problems that neither could solve alone.
The very public disagreements in early 2025 between kernel maintainers and the Rust for Linux team, around how Rust code should wrap the DMA API, came from skipping this step. The Rust developers did not have a deep C kernel context. The C maintainers did not have Rust context. Do not repeat that mistake inside your own organization.
Step 4: Measure Security Outcomes, Not Rust Lines
Track the number of memory safety bugs caught in code review. Track post-merge CVEs in the components that moved to Rust versus those that stayed in C. Track how long it takes your team to ship a new driver. These are the metrics that tell you whether the investment is paying off. Do not measure “lines of Rust written,” which is a vanity metric and tells you nothing.
Teams that measure the right outcomes see the wins quickly. Teams that measure Rust adoption as an end in itself end up justifying the project instead of evaluating it.
Step 5: Plan the Hiring Pipeline Before You Scale
Rust developers are harder to find than C developers, and they cost more. Stack Overflow’s developer survey has named Rust the most admired programming language for nine consecutive years, which is great for developer satisfaction but means the supply side of the market is tight. If your Rust for Linux Development roadmap assumes you’ll hire five Rust developers in the next year, validate that assumption with your recruiting team before you commit. Plan the hiring ramp. Consider training existing C developers internally as a supplement to external hiring.
Common Mistakes Teams Make With Rust for Linux Development
The patterns that fail are as consistent as the patterns that work. Here are the five most common ways teams stumble on Rust for Linux Development, and what to do instead.
1. Trying to Rewrite Working C Code:
The kernel policy is explicit: Rust for new code only. Teams that attempt wholesale rewrites burn quarters of engineering time and rarely ship something better than what they started with.
2. Treating Rust as a Silver Bullet:
Rust prevents memory safety bugs. It does not prevent logic bugs, protocol errors, or design mistakes. A team that expects zero bugs from Rust is going to be disappointed. A team that expects fewer CVEs from a specific, well-understood class is going to be right.
3. Skipping Formal Training:
Reading the Rust book does not make a developer productive on kernel Rust. The ownership model, unsafe blocks, and kernel-specific idioms need deliberate training time. Trying to learn on the job produces bad code and frustrated developers.
4. Underestimating the Toolchain Work:
Rust kernel builds have specific version requirements. Cross-compilation for embedded targets has rough edges. Your CI pipeline needs work before the first Rust code ships. Budget real time for this, not a weekend hack.
5. Ignoring the Hiring Pipeline:
Rust developers are in demand, and they know it. If your adoption plan depends on hiring, validate that plan with recruiting before you commit to it externally.
What Rust for Linux Development Looks Like Over the Next Two Years
The direction of travel is settled. The kernel has made its decision. Ubuntu has made its decision. AWS, Microsoft, Cloudflare, Meta, Volvo, Toyota, and Bosch have made their decisions. Rust is now part of the Linux story, and the percentage of new Linux systems code written in Rust will keep growing quarter over quarter.
What is not settled is how fast any particular organization should move. The right pace depends on your stack, your security posture, your regulatory environment, and how much engineering capacity you can dedicate to learning a new language. A fintech running in a regulated environment should probably move faster than a small SaaS team that does not write kernel code. A consumer IoT company shipping devices that will run for a decade should move faster than an internal tools team whose software gets rewritten every two years.
The one pattern that applies to every organization: do not wait for perfect clarity before starting. Pick one new component, train a small team, measure the results, and decide what to do next based on what you learned. That is how every organization that has succeeded with Rust for Linux Development got started. It is the only approach that scales from a small pilot to a real engineering practice.
If your team is evaluating where Rust for Linux Development fits in your roadmap and needs help scoping the first project, sizing the hiring plan, or running the initial audit on your existing stack, our Rust development services are built for exactly that.
Frequently Asked Questions (FAQs)
No. The explicit kernel policy is that Rust is used for new code, primarily new drivers, while existing C subsystems stay in C. The kernel has about 34 million lines of C and roughly 25,000 lines of Rust as of early 2025. Nobody is rewriting the C. The strategy is additive, not a replacement.
Yes. Android 16 ships Rust kernel code on millions of devices. AWS Lambda runs trillions of executions a month on Rust-based Firecracker microVMs. Ubuntu 25.10 ships Rust coreutils as the default. Volvo and Polestar ship Rust in vehicles. Production use is no longer the question.
Two to four weeks for basic fluency. A full quarter before a developer is productive on kernel or driver work. The borrow checker and ownership model are the main learning curve. Budget real training time. Trying to learn on the job produces frustrated developers and bad code.
No measurable cost at runtime. Rust compiles to native machine code with no garbage collector and no runtime overhead. Compile times are slower than C, which affects developer iteration speed, but the shipped binaries perform comparably to C equivalents. Performance is not the reason teams hesitate on Rust for Linux Development.
Yes. Rust has strong support on ESP32 (Espressif), nRF52 and nRF5340 (Nordic), and most STMicroelectronics automotive chips. ISO 26262 certified Rust compilers are available for automotive safety-critical work. The Rust package registry had more than 11,000 embedded-compatible crates as of early 2024.
A new component you were going to build anyway, ideally in userspace. A new internal tool, a new daemon, a new CLI utility. Userspace Rust has the lowest friction and the smallest learning curve. Once that ships, your team has real Rust experience to apply to higher-stakes work like kernel drivers.