I assume this relates to this conversation? This is a bit of a snippet from a broader discussion (which I found really interesting). Maybe there were other discussions here about GC that I missed.

I would like to respond here, not because I want to continue some heated debate, but because questions of garbage collectors and the _many_ decisions and trade-offs available are very interesting. And they deserve a good treatment.

I don't think it's really fair to characterise pcwalton's position in this way. I think that his comments on Go's GC were quite reasonable and well informed.

Go (which I think (and maybe mistakenly) is the real subject of the parent comment) _does_ have a very innefficient GC right now. But that could be changing in a near-future. Some people are experimenting with adding generations to Go garbage collector. It's not clear how long this will take to accomplish. In addition to the problem of 'building a generational GC that is low latency' there are lots of parts of the runtime which currently rely on memory allocations not moving. So there's a lot of ordinary engineering work to be done to ensure that _everything_ works with a generational GC.

So in this respect Go may soon 'learn from hotspot'.

In order to avoid anyone thinking that I am anti-Go. I am a full time Go programmer. I really like Go, and I think the decision to prioritise latency over throughput was the right choice. But, there is a lot that can be improved in the current GC. I spend a fair bit of my time trying to manage it during they day.

Anyway, it feels a bit sad to see this super super fun topic turn into some kind of grudge. If pcwalton has thoughts on ZGC I would be keen to hear them.