Golang's big miss on memory arenas

Scope of Arenas in Go

• Many commenters say simple arenas are trivial to implement in C/C++/Rust/Zig and even in Go (via unsafe and mmap-backed slices), but the hard part is integrating them with the broader ecosystem.
• The “infectious API” issue is widely acknowledged: to benefit from arenas you must thread arena parameters through many function signatures and libraries, which is at odds with existing Go idioms and APIs.
• Several people note that Go’s experimental arena package was abandoned largely because it didn’t fit naturally into existing libraries; the article is criticized for ignoring this context.

Memory Regions and GC Evolution

• Multiple comments point to Go’s “memory regions” discussion and proposal as a successor to arenas, aiming to give arena-like benefits without pervasive API changes.
• Others highlight ongoing runtime work (GreenTea GC, RuntimeFree, more stack allocation) as evidence that Go has not “capped its performance ceiling.”
• Some argue arenas add little on top of a good generational/compacting GC; others counter that Go’s non-generational, non-compacting GC is now the real limitation for long‑running, memory‑heavy services.

Manual vs Automatic Memory and Other Languages

• There is extended discussion of mixed manual/GC systems: real‑time Java’s scoped/immortal memory, .NET’s ArrayPool and unsafe APIs, D’s restricted GC regions, Rust’s arena crates, OCaml “modes,” SBCL arenas.
• These are cited both as examples Go might learn from and as evidence that carefully designed alternatives to raw arenas exist.
• Odin and Zig are repeatedly mentioned: Odin’s implicit allocator context and Zig’s “always pass an allocator” style are seen as ways to avoid Go’s retrofitting problem.

Practical Performance Experience in Go

• Practitioners processing huge volumes of data in Go report that careful buffer reuse, sync.Pool, and “GC‑free” hot paths can be very effective without language‑level arenas.
• Others complain that the standard library (JSON, crypto, CSV, etc.) is allocation‑heavy and hard to tune, reflecting an early “let the GC handle it” mindset.

Philosophy: Simplicity vs High‑End Performance

• One camp argues Go should stay simple, targeting “fast enough” network services; extreme performance work should use Rust/Zig/C++ or FFI.
• Another camp worries that without stronger memory-control primitives (arenas, regions, or a more advanced GC), Go will be uncompetitive for high‑performance, memory‑sensitive systems.
• Several see the article as overstating the impact of arenas and underestimating both existing Go tools and the cost/complexity arenas would impose.