Comment by RossBencina

> but I don’t get the “hate”

I will put forward some arguments. I do not believe all of them:

GC is for lazy programmers who do not know how to manage memory.

GC takes aspects of memory allocation out of my control. If I control all the things I can get the best performance.

If you care about performance: when your program does not need GC, GC is is pure overhead.

If you care about performance: if you must use GC then you must have a high-performance GC available. So the question is not just GC/no-GC but you have to worry about details of the GC -- it's a leaky abstraction.

If you care about average latency: if you must use GC then you must have a low-latency GC available (i.e. a GC with low and bounded pause times)

If you care about meeting real-time deadlines: if you must use GC then you must have a GC that is guaranteed to meet your timing constraints.

Corollary of the previous three points: GC is not just GC. Someone else's GC is often not the GC you want. Your program requirements can impose strong requirements on the GC algorithm, and you don't always have the necessary control over the GC.

For a particular language, GC algorithm and/or implementation can be a moving target. If the GC developer's goals don't stay aligned with your requirements then you are hosed.

GC results in unpredictable memory allocation performance. Ironing out these performance issues (e.g. by avoiding allocations, pooling objects, etc.) is just as much work as using manual memory allocation, so why bother with GC.

Unless you have allocation patterns or other requirements that really need GC[0], it's easier to just avoid GC.

[0] e.g. some lock-free algorithms depend on the presence of GC