Unpredictable latency is a huge no-no in these days of responsive server applications. Long GC pauses are just not acceptable to many server developers, so I don't think it's correct to consider it only a client-side problem. If you look at the mechanical sympathy mailing list, you'll see a large group of Official Knob Turners for the Java garbage collectors discussing their trade.

The point is not that latency doesn't matter. It's that throughput and latency are more or less a fundamental tradeoff in GC, and latency isn't the only thing that matters.

Yes, that's true, but this GC lets you get more throughput by using more memory, so you can still decide how you want to make that trade-off. But no amount of knobs can save you from a long stop-the-world pause, so they made absolutely the right decision, in my opinion. With multi-core server CPUs, throughput is relatively cheap to obtain. Latency is hard, you can't just throw money at the problem.

Although Go was conceived as a language for the server, that's becoming less apt as time passes. Its being used in many places that the language designers hadn't initially thought of, such as iOS and Android. So the trade-offs they need to make today have to consider all possible use cases, not just the server one.

Also, I think its really important that pause times be as short as possible on the server as well. If they aren't, you'd probably see an unhealthy spike in 90+ percentile responses.

HotSpot has also switched to a low latency collector (G1) as the default GC: http://www.infoq.com/news/2015/07/Oracle-Confirms-G1-Default...

They say[1]: Limiting GC pause times is, in general, more important than maximizing throughput. Switching to a low-pause collector such as G1 should provide a better overall experience, for most users, than a throughput-oriented collector

[1]: http://openjdk.java.net/jeps/248

Throughput is a problem that solves itself. Wait a year and buy a new computer. :)

Not kidding, though, the latency hit from stop the world only gets worse scaling from 32 cores to 64. May as well call it "batch" GC. On the other hand, concurrent GC will keep the same latency but hopefully double throughput on such a machine.

Unlikely. GC, especially non-generational GC, is a memory bound application with low arithmetic intensity and locality. The scaling will likely be sublinear, especially with that many CPUs.

Yes, perhaps a poor assumption. But at what point will the scaling go negative? Even 25% more throughput (same latency) seems preferable to 100% more latency (same throughput). Is it fair to assume latency will be linear with the "server" GC?