You’ve spent weeks perfecting your Rust code. It’s elegant, safe, and fast. Then your boss says: ‘We need to switch to this new STM32 chip. The vendor SDK is C-only. Rewrite everything.’ Your heart sinks. This is the moment Rust loses — not because of memory safety, not because of performance, but because of a war no one is talking about.
Rust didn’t lose to C. It lost to the supply chain. The hardware vendors behind the chips you use — STMicroelectronics, NXP, Infineon — have spent decades building C/C++ SDKs, BSPs, and documentation. When a new board drops, C gets first-party support on day one. Rust gets a community-maintained GitHub repository with three contributors and a warning: ‘Not guaranteed to work on all revisions.’
I asked a senior engineer at a medical device company why they weren’t using Rust. His answer was blunt: ‘We can’t afford the retraining. Every time a microcontroller changes, we need to adapt. With C, the vendor hands us the driver. With Rust, we’d have to fight the hardware ourselves.’ That’s the real bottleneck — not the language, but the economic cost of breaking the vendor’s hand-holding.
The hardware vendor holds the keys, and they only speak C. You can write the most beautiful Rust HAL in the world, but if the chip’s memory map changes, you’re debugging a register-level mismatch while the C team ships their product. The asymmetry is brutal. And it’s not just about technical debt — it’s about who controls the tools your team uses day in, day out.
Think about the last time you saw a vendor commit to first-class Rust support. Outside of Espressif (ESP32) and a few niche players, silence. Why? Because supporting a second language doubles their engineering cost, fragments their documentation, and — most importantly — reduces lock-in. If you can write embedded Rust abstractions that work across multiple vendors, you become less dependent on their ecosystem. That’s a threat to their business model.
Embedded businesses depend on the hardware chain. When the board changes, C gets first-party support; Rust gets a GitHub issue. This isn’t a language war — it’s a supply chain war disguised as a technical debate. The winner isn’t the safer language; it’s the language that comes with the chip’s datasheet.
So what’s the path forward? Not waiting for vendor benevolence. The community has to build a Rust hardware abstraction layer that bypasses vendor lock-in altogether. Think of it as a universal translator: a set of traits and macros that generate register-level access from machine-readable chip descriptions. Projects like svd2rust and embassy are already proving this works. The next step is to make them so reliable that a team can swap a chip without rewriting a single line of application code.
That’s the twist. The solution isn’t to convince hardware vendors to love Rust. It’s to make Rust so independent of any single vendor’s SDK that the hardware becomes interchangeable. Then the economic argument flips: retraining costs vanish because the language abstracts away the chip, and the safety gains become undeniable.
Neutrality is death. Pick a side. I’m taking Rust’s side — not because it’s perfect, but because the current system is broken. The hardware supply chain has been asleep at the wheel, trading memory safety for convenience. If you’re an embedded engineer, stop asking ‘Is Rust ready?’ Start asking ‘How do I build a world where Rust doesn’t need the vendor’s permission?’
The war isn’t over. It’s just starting.
FAQ
Q: Isn't Rust just not mature enough for embedded development?
A: Rust's maturity is not the issue. The standard libraries, HALs, and RTOS support are production-ready. The real barrier is the lack of first-party vendor SDKs, which forces teams to rely on community-maintained, often incomplete, BSPs. That's a supply chain problem, not a language maturity problem.
Q: What practical steps can I take if I want to use Rust in embedded at work?
A: Focus on projects where you control the hardware choice or use open-source boards that already have strong Rust support (e.g., ESP32, RP2040). Expect to spend time building your own hardware abstraction layer using tools like svd2rust. Start with non-critical subsystems to demonstrate safety and reliability before scaling.
Q: Isn't C/C++ good enough for embedded? Why bother with Rust?
A: C/C++ is 'good enough' until memory corruption causes a field failure, a security vulnerability, or a recall. The cost of switching to Rust is high, but the long-term cost of memory safety bugs in embedded systems — especially in medical, automotive, or industrial devices — often dwarfs that initial investment. The contrarian take is that for many mass-produced, low-risk products, C is fine. But for anything where safety or reliability matters, Rust's value proposition is compelling.