[jjoonathan]

I've never been able to figure out the use case that garbage collectors cater to.

For short "one-off" programs, "let process exit clean it up" is not only a reasonable strategy but one that GCs themselves often implement under the hood. For long-lived programs, nothing short of divine intervention is going to relieve the programmer from organizing object relationships to control lifetimes (the "hard work" of manual memory management). GCs get rid of stupid leaks that take 10 seconds to detect and fix but they don't stop your undo queue from holding onto everything since the dawn of time or any of the other classic memory management gotchas that take serious effort to understand and solve. They then add a bunch of nontrivial gotchas of their own: thrashing, stalls, encapsulation penalties, and a cloud of obnoxious complexity should you discover a need to do something yourself (as we see here).

This is the third time today I've (over)heard someone fighting a garbage collector over something that ought to be trivial and would be in a "manual" system. I continue to wonder if GCs are worth the trouble.

[whateveracct]

GC allows advanced immutable data structures to "just work." So that's one use-case. They are always very complicated linked structures that would be a pain to manage manually. Immutable programming is all about making many, many, many short-lived objects, and modern GCs are great at handling those.

[obl]

The advantage of any checked memory management scheme, be it a runtime thing like a tracing gc or a fancy type system, is not to give a tighter over-approximation of liveness but to guarantee that you never under-approximate it.

In other words, preventing memory leaks is undecidable, but you can at least be sure you're not freeing useful memory.