> Yes there exist special, tuned GCs (e.g., Azul's C4, Shenandoah) but Java GCs have to really be super clever compared to the fairly simple strategies that wor

> Yes there exist special, tuned GCs (e.g., Azul's C4, Shenandoah) but Java GCs have to really be super clever compared to the fairly simple strategies that work in Go; It doesn't matter at the end, when those GCs work. There's also ZGC by the way, which has been consistently improving release over release, with sub ms pauses in the latest release for TB sized heaps, something that golang's gc cannot match. > I applaud the ingenuity in Java GC work, but if what you care about is "reasonably good at collecting memory, never pauses for long", the Go language decisions made the GC problem easier. Now if you want to have high throughput and willing to sacrifice some latency, Java's GC selection allows you to do that. Where as in golang you're stuck with the single gc implementation and have to resort to finicky code changes.