Unfortunately, garbage-collected languages have historically not been great for real-time action games. Throughput and performance can be excellent, but without control over the garbage collector pauses can wreck the experience.
For any game that doesn't require smooth frames for the experience, the best language is the one you're most comfortable with (modulo some base level of game dev community)
Edit: on the other hand, Go is a superb candidate for a back-end game server. I'd say the same goes for the network client layer, but the language interop story is not ideal.
I'm making a game in Go, and it runs perfectly smooth on my 240hz monitor (and should run perfectly smooth on 1000hz monitors once we get there).
The garbage collector has not been an issue, because I use memory the same way as if I were doing it in the C language: Allocate all memory used by the game at program launch. I find this scheme easier to work with in Go than in C, because Go's slice type is a natural fit for partitioning these launch-allocated blocks of memory (as they get used and reused during the game).
The garbage collector doesn't get called if you don't allocate. And for the most part¹, it's easy to reason about where Go allocates (if you know C). So my rule is: Always know where your memory is; never allocate.
This may sound like it's going against the grain of Go, but I find Go to be handily amenable to this style. I had my concerns going in, but it just hasn't been a problem. My game runs silky smooth.
At this point, my only concern about using Go to make a game is that bringing the game to consoles does not have a well-trodden path.
¹ So far, the only thing that has surprised me is that assigning a value type (like an int) to an interface allocates! (So another rule is to only assign pointers to interfaces [pointers to memory allocated at launch].) And while this was a surprise to me, I was pleased with how quick the debugging went: I noticed frames were dropping, so I ran go's pprof tool, which led me directly to the (freshly coded) interface assignment that was stealth allocating. (Also, this allocation becomes less surprising the more I think about how interfaces are implemented.)
Thank you for sharing, I've never considered allocating the memory for an entire Go program at launch.
One neat thing that Go has is built-in benchmarking (part of the built-in test package) which shows you allocations per-invocation making it easy to spot the functions which need more work.
Side note: Go's GC will still run without allocations, typically every 10 minutes. But, in your case, it might never find memory to collect. If you truly want to disable the GC, use SetGCPercent or GOGC.
> Unfortunately, garbage-collected languages have historically not been great for real-time action games.
I’ve heard this a lot and even parroted it myself, but in all honesty I would be surprised if this is true today. First, GC does not mean “no control at all” over GC pauses. Secondly, GC pauses are incredibly short in some languages, unless you have to deallocate a lot.
Without first-hand experience, I would assume that GC is not an issue for games today, given that you are aware of how allocations work, and you have access to a good profiler if necessary.
As usual, the best language is most likely the one with the best ecosystem (libs, tooling, docs) around the domain that you’re working in.
For any game that doesn't require smooth frames for the experience, the best language is the one you're most comfortable with (modulo some base level of game dev community)
Edit: on the other hand, Go is a superb candidate for a back-end game server. I'd say the same goes for the network client layer, but the language interop story is not ideal.