The search for easier safe systems programming

Original Article ↗ Hacker News Discussion ↗

Scope of “safe systems programming”

  • Many comments see June as part of a broader trend (D, Chapel, Vale, Hylo, ParaSail, Haskell/OCaml, Swift, Ada, etc.) trying to combine linear/affine types with more ergonomic resource management.
  • Debate over whether “systems programming” should target only low-level, resource‑constrained contexts versus also being pleasant for higher‑level application code.
  • Some argue systems work should remain hard and explicit (Rust, C) while others want more ergonomic, high‑level “control planes” over low‑level cores.

Lifetimes, arenas, and resource ownership

  • June’s “grouped lifetimes” and arenas are compared to region‑based memory management, flow‑based programming, GhostCell‑style patterns, and effect systems.
  • Several note you can approximate checked arenas in Rust using lifetimes, slotmap‑style handles, or libraries, but June bakes it into the model.
  • Questions about guarantees against use‑after‑free are raised; answers suggest copy‑counts or generation counters plus static checks.

GC vs manual allocation

  • One side: GC is “good enough” or better than ad‑hoc alloc/free patterns; many C programs spend a lot of time allocating anyway; modern GCs can be time‑boxed and parallel.
  • Other side: GC is inappropriate for strict real‑time or certain embedded use cases; dynamic allocation is banned in some safety standards; heap‑only allocation harms cache locality and predictability.
  • Some argue manual memory management should focus on minimizing allocations and using pools/arenas; many C/C++ codebases don’t, so GC wins in practice.

High‑ vs low‑level language roles

  • Disagreement on whether low‑level languages should seriously target general application programming.
    • One view: C++ and Rust’s “zero‑cost abstractions” try to hide the inherent maintenance cost of low abstraction; historically, C++ never captured long‑term app‑space share from GC’d languages.
    • Counter‑view: C++ did displace C for many domains; Rust and modern C#/.NET, Swift, D, Nim, Nim‑like, etc., show there is still room for higher‑level but performant systems‑ish languages.

Comparisons with existing languages

  • Rust: praised for ownership model but criticized for lifetimes ergonomics, proc‑macro complexity, and mixing hardware UB with pointer‑level unsafety.
  • C#/.NET: repeatedly cited as close to the “easy, fast, safe” ideal, with AOT, strong performance, FFI, and decent functional features, though some dislike its OOP default and corporate stewardship.
  • Go: lauded for concurrency simplicity but noted as less safe (data races, nil) and much higher‑level than Rust/Zig.
  • Others mentioned positively: Nim, Zig, Crystal, Carp, Hare, Koka, Dhall, proof‑oriented languages (Agda/Idris), and experimental effect/region systems.