[quotemstr]

GC is worth it. What you're proposing is a false economy.

In addition to lifetime management, GC gives you compaction, pointer compression, and fast bump-pointer allocation that doesn't depend on being able to represent your lifetimes as nested arenas.

Modern GC is excellent. Replacing it with manual allocation isn't better, even with guardrails: reference counting is expensive, atomic reference counting doubly so, and free() itself is very far from free.

Sure, you can restrict lifetime shapes, but when you do that, people switch to allocating out of arrays and using indices as pointers, so you're right back where you started with respect to lifetime management.

So what are you saving? You're just replacing the high-performance concurrent mark/sweep microsecond-pause GC someone has written and debugged for you for free with custom convoluted logic that'll probably leak and run slower besides. Why would anyone want this trade?

The elevation of manual memory management to standard performance practice is a generational mistake this industry is making.

[hedgehog]

How modern is modern, and who's implemented it? In recent memory (last decade or so) I've had to work around the GC by doing exactly what you describe with arrays as well as off-heap storage to avoid memory footprint and pause issues across Java, Go, and Javascript. Writing something like say Objective C (with its refcounting, autorelease pools, etc) seemed pretty productive, had predictable behavior, etc. I follow GC development a bit, and often cite some of the stuff Gil Tene has written as an example of clear technical writing and thinking, but I'm not convinced GC is that universally good. Rust's approach has a high ergonomics cost but the Swift people seem to get by.