And we disagree on how best to gain control of latency. Some say that the way to gain control of memory management latency is to track object-level allocations locally using malloc/free-style APIs, arenas, and so on. IMHO, low tail latency achieved through this approach is fragile and often illusory: object reference graphs are often bigger than you expect, and malloc/free-style heap managers (even with thread caches) need to do global synchronization eventually. Arenas work for some cases, but often break down for complex programs. (Look at libapr!)

No, I think GC is the way to control latency of memory handling. Plenty of work on real-time GC shows that you can construct a GC such that if the mutator allocates less than X MB/second you can achieve reclaim latencies under Y ms. The nice thing about these guarantees is that they're global: it doesn't matter how you allocate. All that matters is how much you allocate. It's a metric you can measure and optimize, IMHO, more easily than you can try to bound heap-manager contention and free-SCC size.

Granted, you can come back and point out that it's hard for me to prove I don't have allocation-rate spikes just like it's hard for you to prove you don't have lumpy free()s and malloc pool contention. But IME, it's a lot easier to bound latency rates, because we have good allocation profilers and in many cases you can prove allocation caps. IMHO, it's much harder to reason about long-range interactions of threads touching heaps.

The one primitive I wish we had but (outside BEAM) don't is object coloring. In a GC system, I should be able to allocate objects from different heaps and GC them independently .This way, a can write a subroutine that I can prove locally obeys the allocation-rate rule for my latency target and doesn't do any global allocations without giving up the use of the global heap for other purposes. They'd be a bit like the explicit arenas your tribe uses. (Your child heap would count as one "object" for purposes of parent-heap retention.) You could probably adapt existing multi-pool systems like MPS and ART's GC pretty easily too.

But even absent QoL features like these, modern GC is plenty suitable for programs that need to be responsive.