I don't get how low latency GC can be a good selling point.
I mean, sure, the Haskell's GC is a big downside, but if latency is so important that you have to look how the performance of you GC compares to an usual language, why don't you go with a language with no GC for once?
Because once you start to look at the details, you will need all of them, and how deterministic is Go's GC performance? What's its 99th percentile? What's the 99.999th percentile? Will any of those change in a future version?
Games. I like low latency and garbage collection. I feel like, hey, it's 2017, those things (along with performance within a reasonably small multiple of C's) really should go together.
120 fps is a measure of throughput, not latency. A high frame rate is good, but it's no guarantee that you're not going to drop a frame. Dropping a frame kills the experience, especially in VR.
In any case, .Net (and I gather Java) games typically go to considerable trouble to reduce GC pressure by pre-allocating memory pools and reusing them during execution. For certain kinds of games, like where you load everything in a level up front and don't deallocate until you finish, that can be fine. For other kinds of games, that's a nasty constraint to try to deal with. It ends up bending your architecture in ugly ways that make it hard to develop the game.
I mean, sure, the Haskell's GC is a big downside, but if latency is so important that you have to look how the performance of you GC compares to an usual language, why don't you go with a language with no GC for once?
Because once you start to look at the details, you will need all of them, and how deterministic is Go's GC performance? What's its 99th percentile? What's the 99.999th percentile? Will any of those change in a future version?