Embedded Rust in Production?
Rust’s push into embedded systems is seen as technically promising but socially and economically complicated. Commenters highlight benefits like safer parsers, async support, and better tooling on platforms such as the ESP32, yet note that vendor libraries, hardware tooling, and much of the ecosystem remain C‑centric, often requiring FFI and unsafe code. Many argue the real barriers are developer retraining, scarce embedded‑Rust talent, and “resume‑driven” rewrites, creating a mismatch where companies claim they can’t find Rust engineers while self‑taught Rust developers struggle to find non‑crypto jobs.
Article-specific reactions
- Many find the writeup too vague: almost no detail on what the original ESP32 C bugs were or how Rust specifically solved them.
- Some suspect the improvement came largely from a full rewrite and lessons learned, not Rust per se. Others argue Rust’s safety and ergonomics do change outcomes materially.
- Several embedded devs wanted concrete examples: memory safety issues, parsing bugs, concurrency errors, etc., but didn’t get them.
Rust vs C in embedded
- Consensus that you can do embedded work in Rust on ESP32 (with esp-rs, esp-idf-svc/sys), and some report success in production.
- A recurring point: embedded stacks are heavily tied to vendor C libraries and tooling; using Rust often means FFI layers and extra build/debug complexity.
- Some argue manufacturer HALs are low quality anyway; writing thin Rust abstractions over registers can be better, especially with SVD‑generated crates and projects like Embassy.
- Others note for many MCUs there is still weak Rust support; for typical embedded shops, C/C++ remains more pragmatic today.
Learning curve, complexity, and “people problems”
- Many say the primary barrier is human: C developers reluctant to learn Rust; organizations unwilling to allocate learning time.
- Rust is seen as significantly more complex than Go or Python; borrowing, lifetimes, multiple string types, and unsafe/FFI are cited pain points.
- Some report Rust becomes very productive after the initial hump, moving many bugs to compile time and reducing debugging/time in debuggers.
- Strong debate over whether retraining C devs to Rust is viable; some see it as obviously worthwhile, others as unrealistic for cost/ROI reasons.
Hiring, ecosystem, and “resume-driven development”
- Thread highlights a paradox: companies claim Rust dev scarcity, while many Rust devs struggle to find roles.
- Common complaint: most Rust jobs demand several years of “professional Rust” plus a niche domain (embedded, kernels, SQL engines, crypto). Entry-level Rust roles are rare.
- Some criticize one-off Rust rewrites of existing Python/C tools: they create islands of expertise and technical debt when only one person knows Rust.
- Others argue teams should consciously standardize on a small set of languages, and that choosing a non-standard language is a strategic management decision, not an individual’s.
Safety, unsafe, and value proposition
- Agreement that safe Rust is only as safe as the underlying unsafe and FFI code; nonetheless, isolating unsafe into small, well-documented regions is viewed as a major advantage.
- Some emphasize Rust’s threading/async safety vs C/C#/C++, and its strong type system, as reasons to prefer it where C/C++ would otherwise be used.
- Skeptics question whether these benefits justify ecosystem gaps and training costs for many embedded products today.