Rust for Embedded Systems: Current state, challenges and open problems

Original Article ↗ Hacker News Discussion ↗

Rust’s push into embedded systems is seen as promising but immature, with core crates like `embedded-hal` only recently stabilizing and limited support across many microcontroller families. Engineers highlight real benefits—memory safety, modern tooling, frameworks like Embassy for async/RTOS-like behavior—but point to gaps in peripheral drivers, ecosystem depth, binary size, and smooth C/C++ interoperability as major barriers to adoption. Many expect broader use only when vendors ship first-class Rust toolchains and when debugging, certification, and integration with existing codebases become less painful.

Ecosystem maturity & MCU/driver coverage

  • Many agree embedded Rust has promise but is still young.
  • embedded-hal only recently hit 1.0; people expect that to unlock more stable higher‑level crates.
  • Survey/paper data cited: peripheral crates exist for ~37% of 43 MCU families, often auto‑generated via svd2rust.
  • Practical concern: even if your MCU is supported, common peripherals (OLEDs, gyros, sensors, etc.) may lack usable Rust drivers or be incomplete, pushing people back to C/C++ or vendor SDKs.
  • Some find enough no-std crates for their needs; others see Arduino‑style ecosystems as the exception.

Getting started, RTOS, and concurrency

  • For simple “while(1)” bare‑metal loops, several say Rust is already straightforward: install target, use probe-rs, cargo run.
  • embassy-rs and rtic-rs are highlighted as promising for async and RTOS‑like capabilities without a traditional RTOS.
  • Others say multitasking and non‑blocking HALs are still weak or inconsistent across platforms.

Tooling, debugging, and IDE support

  • Debugging is cited as a significant pain point in the paper; asynchronous/event‑driven designs make it harder.
  • In practice, people report success with probe-rs, GDB, and VS Code + CodeLLDB for source‑level stepping and inspecting data, though it’s not yet at “Visual Studio C++ on MCU” polish.

C/C++ interop and transpilation

  • Interoperability with C is seen as essential, because most vendor SDKs and robotics/robot sensors ship only C/C++ (or sometimes Python) APIs.
  • Rust‑C FFI is documented and widely used, but some argue semantics around ownership, callbacks, and event loops can be tricky, and unsafe Rust can be harder than plain C.
  • C‑to‑Rust transpilers exist (e.g., c2rust), but generated code is often “C in Rust syntax” and unpleasant to maintain; refactoring to idiomatic, safe Rust is non‑trivial.
  • Ideas discussed: smarter translators aided by annotations or even LLMs to infer buffer sizes and convert idioms into safe Rust constructs.

Safety, correctness, and adoption barriers

  • Recurrent theme: many C/C++ developers overestimate their code’s correctness and downplay memory‑safety bugs, which slows Rust adoption.
  • Others counter that in some domains (e.g., where frequent restarts are acceptable) leaks or certain bugs are tolerated; use‑after‑free and corruption remain serious.
  • Rust is seen as strong on memory safety but still complex; some participants speculate a simpler, bounds‑checked C‑like language might capture most CVE reductions with less complexity.

Dependencies and supply chain

  • One concern: Rust projects often accumulate many transitive crates, increasing audit surface and potential for malicious or low‑quality code.
  • Defenders argue:
    • You can keep dependencies minimal, especially in embedded/no‑std.
    • Many crates are of higher quality than typical bespoke C/C++ re‑implementations.
    • Large organizations audit and pin crate versions, and cargo makes source builds easy.
  • Critics emphasize difference between curated distro package managers and uncurated language registries, and see heavy static linking as a security and maintenance downside.

Binary size, performance, and platform constraints

  • Some worry Rust binaries (with statically linked deps) are larger than C++ equivalents using shared libraries, which hurts OTA updates and fitting in flash.
  • Others respond that with care, embedded Rust can be very small and efficient on bare‑metal ARM and similar targets; there is no inherent size overhead, but you must manage features and crates.
  • For very small MCUs (e.g., simple ATtiny LED flashers), participants argue C or even assembly is simpler and Rust adds little value.

Industry culture and trajectory

  • Several comments highlight conservative embedded cultures that stick to vendor BSPs and toolchains to ensure vendor support and certification, resisting custom toolchains or new languages.
  • Expectation from some: broader embedded Rust uptake may hinge on major silicon vendors shipping Rust‑based BSPs and toolchains.
  • Others describe successful real‑world use already (e.g., ESP32, STM32, Nordic) with projects like embassy-rs, citing better power management, nicer tooling, and productivity benefits—while accepting that you’ll often still write or port drivers yourself.