Comment by unscaled
6 months ago
The post's title is quite hyperbolic and I don't think it serves the topic right.
Memory arenas/pools have been around for ages, and binding arenas to a lexical scope is also not a new concept. C++ was doing this with RAAI, and you could implement this in Go with defer and in other languages by wrapping the scope with a closure.
This post discusses how arenas are implemented in C3 and what they're useful for, but as other people have said this doesn't make sense to compare arenas to reference counting or a borrow checker. Arenas make memory management simpler in many scenarios, and greatly reduce (but don't necessarily eliminate - without other accompanying language features) the chances of a memory leak. But they contribute very little to memory safety and they're not nearly as versatile as a full-fledged borrow checker or reference counting.
Ada did this in 1983 before C89 even existed as another point of reference and I'm sure other languages did before that.
(I have not actually checked the standard, but I'm reasonably sure pools were there.)
> But they contribute very little to memory safety [...]
They do solve memory safety if designed properly, as in Ada, but they're not designed in a way that does anything useful here. In Ada the pointer type has to reference the memory pool, so it's simply impossible for a pointer to a pool to exist once the pool is out of scope because the pointer type will also be out of scope. This of course assumes that you only use memory pools and never require explicit allocation/deallocation, which you often do in real world programs.
One should note that Ada evolve quite a lot since 1983, and there are many improvements upon on how to manage resources in the language in a safe way.
There is its own version of RAII, controlled lifetimes, unbounded collections, the dynamic stack allocation on runtime (with exception/retry) is also a way to do arena like stuff, SPARK proofs, and as of recent ongoing standards work, some affine types magic dust as well.