> ...which will result in inferior throughput in actual world benchmarks...
You're telling me that Go's garbage collector, which is optimized for low latency, has worse throughput than the JVM's default allocator, which is optimized for high throughput?
Most garbage collectors are either designed for low latency or high throughput. You cannot optimize for both. The choice for high throughput makes sense for batch programs, like compilers, command-line tools, generating analytics reports, etc. Choosing low-latency makes sense for web services and the backend services behind them.
As fanout increases, the GC latency in backend services becomes much more important.
While generating less garbage decreases the load on the GC so it can sometimes get away with it, complex server apps will not fall into this category. So actually, I really don’t see much value in go, other than the “you can throw as many developer at it, because they can’t really step on each other’s foot” which is actually great for what it was created for.