Committing to Rust for Kernel Code

Original Article ↗ Hacker News Discussion ↗

Linux’s move to allow Rust in kernel development is prompting debate over whether it can safely and efficiently replace some long‑standing C code, especially in drivers where memory safety bugs are common. Supporters highlight Rust’s ownership model, strong static checks, and no_std capabilities as powerful tools for safer systems programming without sacrificing performance, while critics point to slower compile times, complexities around `unsafe` code, and concerns about toolchain dependencies on LLVM and C++. Alternatives like Zig are mentioned as philosophically closer to “C culture,” but Rust’s relative maturity and existing production use in low‑level systems make it the leading candidate for incremental adoption in the kernel.

C→Rust Migration Experiences

  • Migrators report Rust forces deeper thinking about data ownership, lifetimes, and “multiple readers, one writer” patterns.
  • This shift improves design even when writing C later.
  • Error handling via Result/Option and match, inline tests, and documentation tooling are seen as big productivity wins.
  • Several claim Rust codebases are significantly more concise and feel less brittle than their C equivalents.

Dynamic Data and JSON Handling

  • Some say Rust makes highly dynamic tasks (e.g., runtime JSON schemas, unknown DB tables) “slightly harder” than dynamic languages.
  • Others argue it’s mostly extra verbosity, not a real limitation, and point to existing crates that do runtime JSON-schema validation.

Compile-Time Performance

  • Complaints: Rust compile times are “horrible” vs C and can discourage use.
  • Counterpoints:
    • For moderate projects, clean builds complete within a couple minutes on typical laptops.
    • Compared to C++, Rust is often as fast or faster to compile once features are comparable.
    • Heavy dependency trees and traits/macros hurt compile times most; kernel Rust (no_std, few deps) should fare better.
  • Benchmarks comparing Rust and C coreutils show build times within roughly a 2× factor, depending on what setup work is counted.
  • Monomorphization alone is argued not to be the main culprit; a fundamentally different language design would be needed for dramatic gains.

Rust in the Kernel & Systems Programming

  • Strong enthusiasm: Rust’s memory safety is seen as critical for drivers, where concurrency bugs and unsafe patterns are widespread.
  • Evidence cited that memory-safety bugs in the kernel are added faster than they are fixed; Rust is proposed as a structural mitigation.
  • Skeptics:
    • Question Rust’s suitability for bare metal and ultra–low-latency systems, and dislike reliance on C++-based LLVM.
    • Some prefer Zig as culturally closer to C and more hostile to large toolchain dependencies, but acknowledge Zig isn’t stable enough yet.
    • One low-latency trading attempt in Rust reports that the last, performance-critical 20% was extremely hard in safe Rust; unsafe felt more dangerous than C.
  • Supporters respond that:
    • Most low-level work can be isolated in small unsafe sections, with the rest benefitting from safety.
    • Rust can operate at C-like abstraction levels (especially with no_std), while still allowing high-level, zero-cost abstractions when appropriate.

Toolchains and LLVM/GCC

  • The kernel is increasingly built with Clang; bugs remain but toolchain competition is seen as beneficial.
  • Some complain LLVM is hard to build without GCC/binutils/glibc; others argue this is a niche concern and note GCC also depends on C++.