FreeBSD considers Rust in the base system
FreeBSD’s exploration of adding Rust to its base system is exposing a broader split over how far operating systems should go in adopting newer, memory‑safe languages. Supporters argue that Rust offers safer, more maintainable code, better tooling, and a gradual migration path for existing C/C++ projects, while critics worry about toolchain complexity, language churn, dependency management, and imposing extra burdens on existing maintainers. The exchange also touches on alternatives such as forking into a “RustBSD,” the role of package managers like Cargo, and recent tensions in the Linux Rust effort as signs of the social as well as technical costs of such transitions.
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.