Arenas in Rust

Original Article ↗ Hacker News Discussion ↗

Arenas, handles, and safety tradeoffs

  • Several comments stress that arenas can still enable data attacks: out-of-bounds within an arena can corrupt neighboring in-bounds data or syscall buffers, potentially leading to the moral equivalent of RCE.
  • Custom allocators / arenas bypass hardening in system allocators (e.g., MTE), which some find disheartening as general-purpose allocators are getting more secure.
  • Others argue arenas still improve things: bugs become deterministic and bounded within the arena instead of full UB, so failures are less catastrophic even if not “safe”.

Backlinks, cycles, and Rust’s ownership model

  • Back-links (parent pointers, cyclic graphs) are highlighted as a core pain point in Rust.
  • Runtime solutions: Rc<RefCell<T>> with optional Weak for back-refs; works but adds verbosity, runtime checks, and teardown concerns (e.g., stack overflow on deep drops).
  • Compile-time solutions: some discuss lifetime-constrained parent links and two main cases:
    • Single ownership plus back references that never outlive the owner.
    • Multiple ownership with weak backlinks (harder).
  • There’s skepticism that fully compile-time handling of arbitrary cycles fits Rust’s DAG-of-lifetimes model without huge complexity. Traits/generics make analysis harder.

Linked lists, arenas, and performance

  • One camp calls doubly linked lists “approximately useless” today, preferring trees with parent links or arrays + indices.
  • Others strongly defend doubly linked / intrusive lists as essential for:
    • Fast insert/delete/move of known elements.
    • Stable addresses, no extra allocations.
    • Kernel-style queues and completion lists.
  • Rust’s standard LinkedList is acknowledged as non-intrusive and often a poor choice vs Vec/VecDeque; intrusive lists are where the real performance value lies.

Arenas vs pointers and what Rust adds

  • Some see arenas + integer handles as just reimplementing sparse sets; if you add fingerprints/generation counters, Rust isn’t obviously safer than a disciplined C++ implementation.
  • Others reply that Rust still brings safety outside the arena and stronger guarantees around bounds and initialization, so overall risk is lower even if the arena itself is “manual.”

Custom allocators and ecosystem controls

  • There’s a desire for:
    • Stable allocator_api / storage APIs, but with caution to “get it right” before stabilizing.
    • Crate-level policy controls: forbid unsafe, limit proc-macros, dependency depth, and compile-time cost.
  • Existing lints (e.g., unsafe_code = "forbid") partly address this; suggestion that crates.io could automatically expose compatibility with such lints.

Rust vs C/C++/GC languages and learning curve

  • One commenter calls Rust a dead-end due to difficulty and smaller developer pool, arguing GC languages usually suffice.
  • Many responses push back: Rust is seen as much safer than C/C++, competitive with GC languages except where GC is acceptable, and particularly valuable as projects grow.
  • Multiple examples show newcomers struggling with globals, arenas, and linked lists; others respond with patterns like OnceCell/LazyLock, boxing, and passing state via structs rather than true globals.
  • Several note that AI tools plus Rust’s compiler errors significantly ease the learning curve.

Unsafe Rust and intrusive data structures

  • There’s broad agreement that:
    • Using unsafe for low-level data structures (like doubly linked or intrusive lists) is appropriate.
    • The point of Rust is to encapsulate unsafe in safe abstractions, not to eliminate it entirely.
  • One view: the community informally prefers libraries where callers don’t need unsafe, keeping unsafe code “bounded.”
  • Another counters that unsafe libraries are acceptable when needed; an intrusive collections crate is cited as widely used.
  • Unsafe Rust is described as powerful but hard to get right and ergonomically rough; some argue C/Zig are nicer for “unsafe-style” code, while others emphasize Rust’s advantage that unsafe regions are localized and checked more.

Future language directions

  • Some suggest that truly solving cycles/backlinks should be a language feature (e.g., explicit cycle-aware ownership or new borrow-checking models).
  • Links are shared to experimental ideas (e.g., borrow checking without lifetimes) and existing self-referential crates, but commenters note how hard it’s been to design sound, general solutions.