Ask HN: Memory-safe low level languages?

Hacker News Discussion ↗

Tension: Simplicity vs. Safety in Low-Level Languages

  • Thread centers on wanting “a smaller Rust” for systems/graphics work: C-like simplicity, but with real memory safety.
  • Several commenters argue simplicity and safety inherently pull in opposite directions; others claim complexity (e.g., Rust’s type system) introduces its own problems.

Rust: Powerful but “Too Much”

  • Rust is praised and widely used, but some find traits/generics and advanced type features tedious and hard to write, especially when generic bounds propagate everywhere.
  • Borrow checker is less of an issue for these people than the complexity of abstraction.
  • Discussion notes you don’t have to use all Rust features; dyn Trait and careful use of unsafe can reduce complexity.
  • Debate on whether Rust is “truly memory safe”: it’s very strong, but still relies on correctly written unsafe and FFI boundaries.

Zig and C-Like Alternatives

  • Zig viewed as C “fixed,” with explicitness, readability, and powerful compile-time reflection (comptime) to implement generics/partial evaluation in the same language.
  • It’s seen as much safer than C but still less safe than Rust; real-world Zig projects (e.g., Bun) show many segfault issues.
  • Nim, Odin, Jai, C3, etc. are mentioned as promising but all are “beta” with sharp edges, small ecosystems, and limited tooling.

GC and “Low-Level” Languages (C#, D, V, Go, etc.)

  • C# has been used in research kernels with custom runtimes and extended dialects; some argue C# can be “systems” if target platforms allow GC.
  • D has @safe and a GC; BetterC subset reduces runtime needs, but GC makes some see it as more Go-like than Rust-like.
  • V is controversial: critics cite overblown claims, bugs bypassing the checker, and heavy GC use in practice; defenders point to OS projects and optional GC.
  • Go is suggested as a simple, safe option if ultra-low-level control and top performance aren’t required.

Formal Methods, Strong-Safety Approaches, and C Tooling

  • SPARK/Ada and F* (with Low*) are cited as extremely strong on memory safety, but higher on complexity and ceremony.
  • seL4’s multi-level refinement and proof-based approach is highlighted as a “different direction” entirely.
  • C itself is getting safer tooling: Clang -fbounds-safety, Fil-C (Deluge) that instruments C for runtime memory safety, and static/dynamic analyzers (Frama-C, sanitizers, MISRA, etc.).

Memory Safety as a Spectrum

  • One commenter offers a formal definition: language-accepted programs must be statically provable not to perform unsafe memory operations.
  • Others stress memory safety is a spectrum: GC’d languages are often “more” memory safe than Rust; mitigations can make unsafe languages competitive in practice.

Conclusion: No Clear “Small Rust” Yet

  • Many niche or experimental candidates (Austral, Vale, Hare, Hylo, Cyclone, Jakt, Mojo, etc.) are listed, but all have maturity, ecosystem, or design tradeoffs.
  • Consensus: there’s still no widely adopted, genuinely memory-safe, low-level language that sits cleanly between C/Zig and Rust on the simplicity–safety axis.