Rust used to be a GC-based language too - very similar to Go in fact. They didn't abandon GC until sometime prior to the 1.0 release, well after Go first came out.

Early on Rust had optional GC boxing before it morphed into Rc/Arc, it never required GC of heap allocated objects like Go/Java/C# et al. Deterministic resource management has always been the default with Rust.

I guess every language has its devotees. Go is no exception. My own personal experience with talking to more than a few of these people were that they tended to be a bit... naive and overly optimistic, which is fine, but often the lessons of history were ignored.

The way I like to put it is Go devotees operate under 2 rules:

1. Whatever your complaint about Go is, it's totally not a problem (eg stop-the-world GC pauses, a longstanding issue that any experienced Java engineer could commiserate at length about);

2. Even if it is a problem--which remember it is not--it's totally fixed in Go 1.(N+1) where 1.N is the current version.

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.