The Rust-in-embedded conversation in 2026 is two arguments dressed up as one. Half the internet says Rust is finally ready for production embedded and the C-era is ending. The other half says the toolchain is immature, the borrow checker fights against ISR code, and the productivity loss outweighs the safety gain.

Both halves are right about different projects.

The frame that helps is this: Rust earns its keep on a minority of embedded projects — call it one in five — and costs more than it saves on the rest. The interesting work is figuring out which kind of project you have before you commit a team to either side.

This is the read from where I sit. We have evaluated Rust on engagements where it was being considered, refactored C codebases where Rust had been tried and abandoned, and seen one team ship a Rust firmware product into the field. None of those experiences support a categorical position. All of them support a calibrated one.

The 20% Where Rust Earns Its Keep

The projects where Rust delivers real, measurable value share four traits.

1. The firmware ships to people who cannot update it

Implantable medical devices. Automotive firmware in vehicles with a 12-year support lifecycle. Industrial controllers in plants where the OT network is air-gapped and updates require certified procedures. When the cost of a memory-safety bug shipping to the field is six figures or higher per incident, Rust’s compile-time guarantees stop being a productivity tax and start being insurance.

2. Greenfield, not brownfield

A new product programme started in Rust gets the language’s full benefit. An existing C codebase being incrementally migrated to Rust pays the FFI tax on every boundary crossing, fights every legacy data structure, and ends up with the worst of both languages. The teams I have seen succeed with Rust started in Rust. The teams I have seen abandon Rust were halfway through a migration when they did.

3. The team has at least one engineer who already knows Rust well

Rust has a steeper learning curve than the marketing acknowledges. Six months of Rust by an experienced systems programmer produces code that competes with their C. Six months of Rust by a competent C engineer with no prior Rust produces code that fights the compiler more than it ships features. The senior-engineer floor is real, and most teams badly underestimate it.

4. The product runs on silicon Rust supports well

ARM Cortex-M (Nordic, STM32, Microchip SAM) has mature support through cortex-m-rt, embassy, and chip-specific HALs. RISC-V is improving fast but uneven across vendors. Anything Xtensa (the original ESP32, S2, and S3) has community support but not first-class; the RISC-V C-series (C3, C6) is the separate story noted above. Anything obscure or in-house silicon is a research project. Check the HAL for your chip before committing to the language.

When all four traits are present, Rust is a defensible choice. The memory-safety guarantee, the no-data-races guarantee, the ergonomic improvements in async embedded work — they compound. Teams that fit this profile ship Rust firmware that is genuinely harder to break than the C equivalent.

The 80% Where Rust Costs More Than It Saves

Most embedded projects are not in the 20% above. Most are some version of: brownfield codebase, mixed-experience team, twelve-month timeline, products that get updated, silicon where the C HAL is mature and the Rust HAL is community-supported.

In those projects, four costs show up consistently.

The borrow checker fights ISR-heavy code

Interrupt service routines need access to shared state with specific timing and locking semantics. Rust’s borrow checker is correct about why that shared state is unsafe, but the patterns to satisfy it (Mutex<RefCell<T>>, critical_section, custom statics) are verbose, error-prone if applied incorrectly, and slower for engineers to write than the C equivalent. The safety guarantee is real. The productivity tax in ISR-heavy code is also real, and on most products the ISR layer is a meaningful chunk of the firmware.

The toolchain is mature, but not equivalent to IAR or Keil

probe-rs is solid. cargo-binutils works. defmt for logging is genuinely excellent. None of these match the integrated debugger experience of a paid IAR or Keil environment when you are chasing a memory corruption bug at 3 a.m. The gap is closing every year, and teams comfortable with command-line workflows do not feel it as sharply. Teams that have built their debugging muscle on integrated commercial IDEs will feel a productivity hit for the first six to twelve months.

Vendor SDKs are still C-first

Nordic, STM, NXP, Renesas — their reference code, application notes, vendor support, and community libraries are written for C. Using a Rust HAL means either translating vendor C examples by hand, accepting a community-maintained wrapper that may lag the C SDK by months, or writing FFI bindings for every vendor library call. This is workable but adds friction to every problem the team encounters.

Hiring is harder

The pool of embedded engineers with strong Rust experience is meaningfully smaller than the pool with strong C experience. For a team that needs to scale, this is a real constraint. The pool is growing, but it is not yet large enough that Rust experience is assumable on a hire.

Each of these costs is survivable. None of them is fatal. But on a project where the safety value is modest — because the product gets updated, because field bugs are recoverable, because the C codebase is solid — the costs add up to a productivity hit without a proportional safety return.

What This Means for Your Next Project

The honest read is this. If you are about to start a new embedded project, ask the four questions:

If you answer yes to all four, Rust is worth seriously considering. If you answer yes to three of the four, Rust is a defensible choice with managed risk. If you answer yes to two or fewer, C is probably the right tool.

This is not a permanent verdict. The Rust embedded ecosystem is improving genuinely fast. In 2028 the answer may be different. In 2030 it almost certainly will be. The point is not to predict the future. The point is to not commit a team to a language because of how the conversation feels online, when the engineering reality on a specific project is more nuanced than the conversation allows.

The Conversation Worth Having

The most useful thing an embedded engineering team can do in 2026 is stop treating Rust as a referendum. The right question is not “is Rust ready?” It is “for this product, on this team, with this silicon, on this timeline — is Rust the right tool?” That question has different answers for different projects, and a team that asks it honestly will land in a better place than a team that defaults to either side of the broader debate.

For the 20% of projects where Rust is the right answer, the safety win is real and the productivity tax is recoverable. For the 80% where it is not, C remains a tool that ships products. Both can be true at the same time. They usually are.

Frequently Asked Questions