"I think your complaints could be addressed with a simple extension to pause the collector therefore introducing determinism"
I don't think that scales to multiple threads. Remember, the GC is global. With a lot of goroutines, you're going to end up delaying GC far too long if any of them can block the GC.
These sorts of things are the reason why it's considered a bad idea to muck around with the GC settings in e.g. the JVM unless you really know what you're doing. The right way to avoid GC pauses in a GC'd language is to avoid generating garbage; e.g. with free lists.
GC doesn't have to be global or blocking. If you look at the GC in CLR/.Net 4+ then it can run GC on low priority background threads.
I know Go's GC isn't there yet, but it's easier to centralize a performance improvement under this model i.e. GC improvements will lead to global improvements rather than case by case.
There's more than one way to skin a cat on this one.
> The right way to avoid GC pauses in a GC'd language is to avoid generating garbage; e.g. with free lists.
And Go makes it much easier to avoid generating garbage than pretty much every other GC language around, already "by default" Go code tends to generate dramatically less garbage than for example Java, and when you care, you can further fine tune it to produce even less garbage.
Genuine question, from ignorance: How does Go create less garbage than Java? I can certainly appreciate that a lot of the common frameworks used in JEE development may be memory-hogs, but the language itself?
I don't think that scales to multiple threads. Remember, the GC is global. With a lot of goroutines, you're going to end up delaying GC far too long if any of them can block the GC.
These sorts of things are the reason why it's considered a bad idea to muck around with the GC settings in e.g. the JVM unless you really know what you're doing. The right way to avoid GC pauses in a GC'd language is to avoid generating garbage; e.g. with free lists.