Cross-platform Rust rewrite of the GNU coreutils

Original Article ↗ Hacker News Discussion ↗

A long-running effort to reimplement GNU coreutils in Rust is drawing renewed attention as its compatibility test suite now passes most of the GNU tests. Commenters weigh potential benefits — memory safety, cleaner modern code, easier cross-compilation, and a permissive MIT license that avoids GPL obligations — against concerns over longevity, subtle incompatibilities, and whether a non-GPL rewrite undermines the goals of copyleft. The project is seen as particularly appealing for Windows, macOS, and embedded environments, but many doubt it will replace GNU coreutils across mainstream Unix systems in the near term.

Project goals & status

  • uutils is a decade‑old Rust project aiming to be a cross‑platform, drop‑in replacement for GNU coreutils.
  • Differences from GNU behavior are explicitly treated as bugs; a shared test suite shows passes now significantly outnumber failures.
  • Several commenters note “last 10% takes 50% of the time” and expect people to wait for near‑perfect parity before using it as the system default.

Adoption and use cases

  • Many doubt traditional Unix/Linux distributions will switch soon, given GNU coreutils’ 30+ year track record and ubiquity.
  • Others see clear niches: macOS (avoiding very old BSD tools), Windows (where WSL/VMs/Cygwin are awkward, slow, or banned), embedded systems, and NixOS‑style setups where swapping coreutils is easy.
  • Cross‑compiling Rust is seen as simpler than C in some environments.

Rust vs C: safety, maintainability, performance

  • Pro‑Rust arguments: memory safety, better integer/UTF‑8 handling, stronger tooling, and more approachable modern code than “ancient, terse, clever” GNU C sources. Some report large reductions in real‑world bugs after moving embedded/robotics code to Rust.
  • Skeptics note coreutils have few serious CVEs and mostly non‑memory bugs; they see logic/semantic bugs as more important than memory issues here.
  • Concerns are raised about binary size and portability compared to BusyBox/Toybox and plain C.

Licensing: MIT vs GPL

  • The MIT license is a major flashpoint.
  • Critics view this as an attempt to escape GPL “virality,” enabling corporations to integrate and extend core tools without sharing changes, and as part of a broader, worrying drift away from copyleft.
  • Supporters argue permissive licenses ease adoption, reflect existing practice (many key components are already BSD/MIT/Apache), and that GPL obligations (esp. v3/AGPL) are a real burden for companies.
  • There is back‑and‑forth on whether copyleft actually delivers better outcomes for users and smaller companies, and on corporate reluctance to contribute under GPL.

Legality and clean‑room concerns

  • Some question whether a like‑for‑like MIT rewrite of GPL’d coreutils is really independent, pointing to earlier findings of copied identifier names and the difficulty of guaranteeing “no one looked.”
  • Others emphasize that independent reimplementation is legal; clean‑room is a defense, not a requirement, and accuse the skepticism of being FUD.
  • Overall legal status is debated but unresolved in the thread.

Broader reflections

  • Discussion touches on project longevity (Lindy‑effect arguments vs criticisms of that reasoning), the tradeoff between historical size‑optimized C and modern readability, and using projects like this as a stress test of Rust’s suitability as a “new C” for system tools.