Everybody thinks about garbage collection the wrong way https://devblogs.microsoft.com/oldnewthing/20100809-00/?p=13203
> When you ask somebody what garbage collection is, the answer you get is probably going to be something along the lines of “Garbage collection is when the operating environment automatically reclaims memory that is no longer being used by the program. It does this by tracing memory starting from roots to identify which objects are accessible.”
> This description confuses the mechanism with the goal. It’s like saying the job of a firefighter is “driving a red truck and spraying water.” That’s a description of what a firefighter does, but it misses the point of the job (namely, putting out fires and, more generally, fire safety).
> Garbage collection is simulating a computer with an infinite amount of memory. The rest is mechanism. And naturally, the mechanism is “reclaiming memory that the program wouldn’t notice went missing.” It’s one giant application of the as-if rule.
In this sense, "tracing" GC, reference counting, and in fact even Rust's borrow checker are *all* garbage collection mechanisms. (That Rust's is done at compile time is interesting, but it's still GC under the definition above.)
@cwebber I like the bit about how automatic garbage collection isn't meant to liberate you from tracking resource life times or cleaning up after yourself, because you don't have any strong guarantees over when many GC finalizers run.
I'm reminded of an old joke:
Q: When are dynamic memory allocations freed?
A: When the program closes 😎
