Google says replacing C/C++ in firmware with Rust is easy

Original Article ↗ Hacker News Discussion ↗

Scope of Google’s Claim

  • Several comments note the article reflects an Android engineering group, not a unified, company-wide “Google says”.
  • Readers caution against interpreting it as an official corporate mandate.

Rewriting vs Gradual Adoption

  • Broad agreement that wholesale rewrites of large C/C++ codebases are rarely worth it.
  • More realistic pattern: write new components in Rust and interoperate with existing C, or incrementally replace peripheral code.
  • Rust↔C FFI is seen as solid and a practical migration path.

Rust vs C/C++ Ergonomics and Learning Curve

  • Many C/C++ developers acknowledge Rust’s safety benefits, especially around memory.
  • Some report a steep initial productivity drop; C “muscle memory” doesn’t transfer cleanly due to semantic differences (ownership, borrowing).
  • Others say the dip is short-lived, and once over the hump, refactoring and large-scale changes feel safer and more powerful than in C++.
  • Concerns include verbose generics, phantom types, and potential for “clever” abstractions that hurt readability.

Jobs, Adoption, and Language Longevity

  • Mixed views on demand: some see “tons of Rust jobs”, others report almost none in their local markets, often limited to crypto.
  • Students note Rust has near-zero entry-level positions; C/C++ remains the practical route.
  • Many expect C/C++ to persist for decades due to massive legacy codebases, similar to COBOL.
  • Some argue new critical infrastructure increasingly starts in Rust, especially where safety is paramount.

Embedded/Firmware and Real-Time Concerns

  • Embedded developers highlight pain points: rough no_std experience, complex Peripheral Access Crates (PACs), immature Rust RTOS options, and lack of native support in major existing RTOSes.
  • Debate over LLVM-based toolchains for hard real-time: one side claims optimizations/code motion make timing non-deterministic versus non-optimized GCC; others counter that similar controls exist in LLVM, and the criticism is vague.
  • Unsafe Rust is viewed as less ergonomic, and ultra low-level firmware may still need unsafe pointer-heavy code.

Safety, Correctness, and Alternatives

  • Some argue formally verified C (e.g., seL4-style) or Ada can provide stronger guarantees than Rust, though at high specification cost.
  • Others see Zig or “safer C/C++ subsets” as more natural evolutions for C programmers.
  • For higher layers, JVM/Java, Go, Swift, Nim, etc., are mentioned as possibly better trade-offs depending on domain.
  • Governments (e.g., DoD) pushing “memory-safe languages” is seen as a strong long-term driver toward Rust-like options.

Ecosystem Maturity, Tooling, and Stability

  • Complaints about Rust’s compile times, frequent non-trivial bugs (e.g., optimizer/float, command escaping), and pressure to keep toolchains updated.
  • Tooling and ecosystem are improving quickly but still viewed as a “moving target”, which is uncomfortable for long-lived commercial firmware.

Community and Discourse

  • Some participants perceive parts of the Rust community as defensive or zealously promotional, which makes skeptics wary.
  • Thread itself shows friction between enthusiasts and cautious practitioners, particularly around acknowledging real costs of adoption.