I'd use either the JVM or the CLR long before Go, though.
The reason is because you don't control the GC and don't even necessarily know what exactly drives the decisions it makes. So once you want to go beyond a certain level of performance, there is no right answer. You are just randomly trying stuff and kind of flailing.
In C++ (or another direct-memory language), there is a right answer. You can always make the memory do exactly what you want it to, and there's always a clear path to get there from wherever you are.
I appreciate the flexibility and choice that a direct-memory language provides, but I think "randomly trying stuff and kind of flailing" is over-the-top. On the JVM you can control the GC quite effectively, with an understanding of the JMM and some experience its behaviors become largely predictable, and profile-directed memory optimization can be tedious, but certainly isn't random. Most Java developers I know are sometimes surprised by the JVM's behaviors...but then, most Java developers I know aren't terribly interested in how the JVM works.
(My professional, non-game work is historically mainly on the JVM. I use the CLR for my game projects because even mobile platforms have an embarrassing surplus of performance relative to my needs and it's a lot more cross-platform than the JVM. I'm comfortable enough in C++, but I'm much slower at working with it--and I'm slow enough that I need all the help I can get!)
This is why the approach I'm experimenting with is build something very much like a custom allocator in Go, for all values that are allocated in significant numbers. I'm hoping that this will take enough pressure off the GC that it will keep pauses below the threshold where they matter (see above for a caveat about needing a concurrent or incremental GC to avoid long, but less frequent pauses). For what it's worth, I'm not 100% certain that this approach will work well enough, but I'm hoping to get some data that we can use to debate this in more concrete terms.
If this does work well, awesome. If not... well, I'm still tinkering with Rust, but I found the type-parameter explosion off-putting enough that I decided to stick with Go for my first round of experiments. I'm curious how your experience with more limited (as I understand it, perhaps incorrectly) allocation annotations are working out in Jai. After all, I'm not dead set on using Go -- I just want to avoid writing C++ for hobby games if I can possibly avoid it :)
Only if you write your own memory allocator, otherwise relying on the compiler provided allocator is no different.
Possibly only because they have been around for longer. The CLR 1.0 GC was a terrible beast. I'm sure that the earlier Java GCs were horrible things, too.
> sufficiently complicated game will spend a lot of time dealing with memory issues.
This is precisely why gamedevs are going for data oriented design, it all does come down to this at the end of the day. In theory a GC doesn't actually get in the way of DOD, because in the strictest definition it simulates infinite memory (it is, strictly, not a memory reclaiming device). GCs are getting better and better at doing this with less and less overhead. The newest concurrent CLR GC is pretty impressive, it very nearly never has to stop-the-world.
