FreeBSD considers Rust in the base system

Original Article ↗ Hacker News Discussion ↗

Scope of Rust in FreeBSD

  • Some read the proposal as “Rust in base userland, not kernel,” but the exact scope is seen as unclear.
  • One side argues it’s about enabling new code in Rust alongside existing C/C++, not rewriting the system.
  • Others suggest if people want a Rust-heavy OS, they should fork to “RustBSD” or similar and experiment there.

Toolchain and Self‑Hosting

  • FreeBSD already ships a C++ compiler largely because LLVM/GCC are written in C++, and the system must be self-hosting.
  • Critics note that most base userland isn’t C++; C++ is “along for the ride” because of compilers.
  • Adding Rust implies another toolchain and possibly another LLVM, which some see as extra maintenance burden.

Rust vs C/C++: Complexity and Ergonomics

  • Pro‑Rust comments: Rust is simpler than modern C++ in practice, with clearer idioms, safer ownership, strong enums/tagged unions, pattern matching, and a cohesive toolchain (cargo, tests, benches).
  • Counterpoints: Rust’s lifetimes, borrow checker, async, and references introduce different complexity and ongoing ergonomic costs; idiomatic Rust is “differently complex,” not simply easier.
  • Disagreement over productivity: some report becoming more effective in Rust than in C++ within months; others doubt this and emphasize Rust’s compile times and learning curve.

Security and Memory Safety

  • Many see Rust’s main value as memory safety for kernels, servers, parsers, etc., aligning with broader “memory-safe language” recommendations.
  • Others caution that unsafe FFI boundaries can become new vulnerability points, potentially reducing net security if handled poorly.
  • Some argue alternatives (e.g., Zig or a funded new language) might offer a better C replacement without Rust’s ecosystem baggage.

Ecosystem, Package Management, and Build Integration

  • Cargo is widely praised as superior to C++ build/dependency setups.
  • Skeptics fear “language package manager dependency hell” (comparing to npm/pip/composer) and prefer OS-curated libraries.
  • One suggested compromise: allow only std and in-tree Rust libraries for base system components; no arbitrary crates.

Forking vs Upstream Evolution

  • One camp advocates forking (e.g., a RustBSD, like DragonFly BSD was from FreeBSD) to prove ideas, then upstreaming.
  • Others argue heavy forking fragments effort, makes long-term rebasing painful, and that most work should happen within the main project.

Community Dynamics and Kernel Politics

  • Several posts highlight toxic debates around Rust (both enthusiasm and hostility), including a Rust-for-Linux maintainer stepping down over “nontechnical nonsense.”
  • Some kernel developers fear being obligated to understand Rust or maintain C semantics for Rust bindings; others insist no one is trying to force anyone to learn Rust.
  • There’s concern that a perceived anti-Rust stance will quietly discourage Rust developers from contributing to C-based projects like FreeBSD.

Alternatives and Long‑Term Outlook

  • Some worry FreeBSD “may lose out long-term” if it can’t host Rust in base, as upstream projects migrate from C to Rust.
  • Others believe it’s acceptable for FreeBSD to remain C/C++-centric and that not every large system must adopt Rust.