Embedded Rust vs C in 2026 · the pragmatic decision

Embedded Rust in 2026 is the opposite of 2022. The community settled on a default stack (probe-rs, Embassy, embedded-hal 1.0), the tooling works, and safety-critical teams now default to Rust for new Cortex-M / RISC-V / ESP32 work. C is not going anywhere though. Here is the honest decision frame we use.

When we pick Rust

• Greenfield project on a modern MCU (Cortex-M, RISC-V, ESP32, RP2040).
• Memory-safety matters (medical, automotive, finance).
• Async concurrency is non-trivial. Embassy is a genuine productivity win.
• Build reproducibility is important. Cargo plus probe-rs beats the C/Makefile mess.

When we stay with C

• MISRA-C certification is required. Rust tooling for cert is still immature.
• Sub-16KB flash targets. Rust binary footprint is catching up but still larger.
• Legacy toolchains (AVR, old PIC, STM8). Rust support is unreliable.
• Hardware vendor ships only a C SDK. Binding-generation bias adds risk.

The Embassy moment

Embassy (https://embassy.dev) made async embedded practical. Before it, async-on-MCU was a research topic. Today it is the default for any firmware that juggles multiple async IO operations (BLE + Wi-Fi + sensor readout simultaneously).

#[embassy_executor::main]
async fn main(spawner: Spawner) {
    let p = embassy_stm32::init(Default::default());
    let mut led = Output::new(p.PB7, Level::High, Speed::Low);
    loop {
        led.toggle();
        Timer::after_millis(500).await;
    }
}

Binary size reality

On a Cortex-M4, a minimal no-std Rust binary lands around 4-6 KB. Equivalent C is closer to 1-2 KB. For a flagship-MCU project (Cortex-M33 or ESP32-S3), this is immaterial. For a ULP BLE-only tag on a 16KB device, it still rules Rust out.