> The only reason you hear less "crazy" Go GC stories is because Go has never been tested as much as the JVM under different application requirements.
It is definitely true that the JVM had been thoroughly road tested compared to Go, but your conclusion is unsound. Go was designed to specifically avoid this pitfall.
The 32-bit GC issue is an unfortunate shortcoming of the GC implementation, which will be resolved in Go 1.1 early this year. The issue was merely an artifact of dead simple conservative GC implementation.
OTOH, the memory model of the JVM is intractably linked with its design. Software that runs on the JVM must generate garbage, and so the JVM must include a highly sophisticated GC.
Remember how appallingly bad the JVM was when it was just a few years old? It didn't come close to where we are with Go today. We have only scratched the surface with GC (and other optimizations) for Go.
It is definitely true that the JVM had been thoroughly road tested compared to Go, but your conclusion is unsound. Go was designed to specifically avoid this pitfall.