This comment is transparently trying to incite a flame war, but I'll try to take it on a more productive tangent.

> eg stop-the-world GC pauses, a longstanding issue that any experienced Java engineer could commiserate at length about

This is a really interesting example, because it shows the lack of nuance in the anti-GC position. By your logic, because Java's 100ms GC pause times have been problematic (and yes, I'm aware that Java's upcoming GC will boast significantly improved pause times and that it's theoretically possible to tune a Java GC for low pause times even if no one has managed it in production) Go's 5us pause times will be equally problematic. Because a pause is a pause, right--why should we muddy the waters with considerations like "duration"?

Single- or double-digit microsecond pause times completely change the conventional wisdom about the kinds of applications GC is suitable for. There are still lots of hard real time applications that Go's GC won't be suited for, but there are many soft real time applications for which Go would be fine (or at least the issues will be libraries or support for target architecture/platform and not GC).

> This is a really interesting example, because it shows the lack of nuance in the anti-GC position.

I wouldn't call my position strictly anti-GC. I would simply say that GC isn't the panacea it's made out to be and it is at least in part a false economy for at least three reasons:

1. You may need to tune your VM/GC parameters (as you mention). There's a cost to this;

2. GC can make it harder to identify memory leaks (which are still a problem through, for example, dangling references). I've worked on C++ systems where we instrumented many things including process size, which was basically just a flat line. As soon as it wasn't, you knew there was a problem. And this was for a server that read about ~6GB/second off a NIC.

3. Crashing a program due to accessing unallocated memory tends to give a more immediate signal of a problem, which is more often than not better for development.

My experience at CERN ATLAS HLT means that those C++ processes would also have a highly tuned custom multithreaded memory allocator, malloc() and new aren't even in the game to start with, and most likely one is doing a custom protocol at IP level.

Well, my personal experience with C++ developers is, that they are a bit ...naive and overly optimistic, when it comes to taking a look at the real world, with real deadlines. "I just write my own half assed string class" comes to mind... As if they are developing in a vacuum, with no competition out there. This really pisses me off.

Pauseless concurrent collectors have existed for decades.