With all improvements to the GC, in 2018 Go is ready to develop real-time AAA games? In the past there is discussions that Go is not very well for game development. (GC latency)

I would think the biggest barriers (no pun intended) to using Go in CPU-bound apps like games would be the lack of mature compiler optimizations, compared to GCC and LLVM. Additionally, the performance of cgo can cause problems when linking to libraries like Vulkan that can't effectively be lowered into syscalls.

I also think that throughput of memory allocation, not just latency, matters a lot more than people give it credit for.

> Additionally, the performance of cgo can cause problems when linking to libraries like Vulkan that can't effectively be lowered into syscalls.

Agreed. But you also ask for very fast memory allocation, which implies a bump allocator, which implies a copying GC, which implies pinning objects shared with C through cgo (Go's foreign function interface), which would probably make cgo even slower.

> I also think that throughput of memory allocation, not just latency, matters a lot more than people give it credit for.

At 60 fps, minimizing latency is critical. You have to optimize this first. When your longest GC pause is well below 1/60 s, then you can optimize throughput of memory allocation.

Anyway, most AAA video game engines being written in C/C++, my guess is they don't use a bump allocator, which means they do quite well with allocators like tcmalloc or jemalloc, probably by allocating as much as possible early, and using object pools.

I agree that these are all tradeoffs. My view is that languages like Rust and C++ exist for a reason, and demanding games are among the domains that they're most appropriate in. :)

Note that Unity is an existence proof that most games can get by just fine with high-level logic in GC.

And with a language that is not particularly fast. And with a GC that's way worse than what Go has.

Go would be fine for lots of game dev, imo.

Note that I'm not sure how FFI calls out of Unity's VM compare to those of cgo.

ah, good point. much faster than cgo. so probably that would kill you in go.

i wonder if it's possible to speed up ffi in go...

You wrote that Unity FFI is much faster than cgo. I'd be interested in knowing more about this. Why is it faster? Can you share a link to some reference material and/or benchmark?

my understanding is go is slow because each function call has to copy over to a bigger stack (goroutines have tiny stacks to start, and grow on demand, but c code can't do that, natch) and because it has to tell the goroutine scheduler some stuff for hazy reasons.

this github issue has a lot of interesting discussion of go ffi: https://github.com/golang/go/issues/16051

these benchmarks https://github.com/dyu/ffi-overhead seem to show that a c call via cgo will be about 14 (!) times slower than a c call from c# in mono, which itself is about 2 times slower than just a plain c call.