This was an anti-pattern of the runtime model that Java inherited from Smalltalk. Tuning the GC used to be an arcane art. There was also a lot of effort put in

This was an anti-pattern of the runtime model that Java inherited from Smalltalk. Tuning the GC used to be an arcane art. There was also a lot of effort put in by programming shops to just reducing GC pressure as an optimization. This is why I appreciate Golang's pragmatic approach of not using the GC by avoiding the heap. The main benefit to having GC is to make initial development faster by reducing the severity and frequency of mistakes. It's really there as a safety net, not as a foolproof end-all be-all. Use tools in a way which plays up their strengths. It's hard to tune a GC to be super-fast. It's easy to profile and find your biggest memory leaks.