I don't completely disagree with your point, and I would not be a person to advocate Go for game development, but "wholly unsuitable" isn't true. A large number of successful games are released that depend on runtimes with similar garbage collectors. Most notably games running on the JVM and CLI. These are "real games" with real performance considerations.
See: Minecraft, Terraria, Magicka, AI War, and many more.
"To give the programmer this flexibility, Go must support what we call interior pointers to objects allocated in the heap. The X.buf field in the example above lives within the struct but it is legal to capture the address of this inner field, for instance to pass it to an I/O routine. In Java, as in many garbage-collected languages, it is not possible to construct an interior pointer like this, but in Go it is idiomatic. This design point affects which collection algorithms can be used, and may make them more difficult, but after careful thought we decided that it was necessary to allow interior pointers because of the benefits to the programmer and the ability to reduce pressure on the (perhaps harder to implement) collector."
To be fair I don't think this is a blocker for Go to implement GGC and CGC. .NET supports interior pointers too, for example. You just have to design your allocator right to allow the card marking to work.
In practice I think that the biggest problems are compiler related and affect both Go and Rust. Go and Rust both use conservative GC on the stack and as a result they take a lot of shortcuts. For example, LLVM (and GCC as far as I'm aware, though someone like DannyBee may correct me here) loses the distinction between integers and pointers by the time they get to the machine instruction level, which makes a lot of optimizations easier to implement but also making it impossible to generate precise stack maps. Fixing this would be a lot of hard work. It's probably easier in the Plan 9 compilers, of course, though I suspect it's still going to be a lot of hard work.
That said: Aren't the equivalent pointers in .Net _only_ allowed/usable if you pin your object? If you tell the GC explicitly 'please don't move that, I'm pointing to that thing here'?
That's hard to bolt on to Go, imho. For Go it seems to be implicitly allowed, in .Net you have to ask explicitly?
Go's GC is non-moving, exactly because they can't precisely know what a pointer is and what is just some random int.
So it's basically as if all objects are pinned in Go.
I don't expect that to change. There are probably tons of Go code out there which will break in response to a change.
I guess it will be pushed back to some mystical "2.0" release, along with Generics.
Agree for Minecraft, it has definitely "lags" to an extent that there are a lot of forums discussing how to tweak the configuration to improve the performance. The lags are very disturbing and I think it has to do with memory management because it sets in after some time of playing.
It certainly fits the profile of GC stutter. I'm told it makes some bad decisions about handling objects, triggering pathological behaviour in the collector but that's second-hand info at best.
See: Minecraft, Terraria, Magicka, AI War, and many more.