Nice to see such a topic come up.
I am the developer of Astral Divide, which is entirely written in Go: https://store.steampowered.com/app/2597060/Astral_Divide/
When I started two years ago, I basically had to choose a language and a package/framework, so I'd like to share my experience about it.
First, about the package, there are two major ones for 2D games, which are Ebiten(gine) and Pixel.
I initially chose Pixel, because it seemed more documented at the time and had a bigger community. Overall, it was good as long as the game was simple, but unfortunately I regretted this choice later.
Don't get me wrong, I am not here to discredit the author, because there is a phenomenal amount of open source work that was done, and I am thankful for it.
But as my game grew more complex, the engine started to cause big architectural challenges, memory leaks (it does not correctly garbage collect OpenGL's objects for example), and it's multi-threading model is flawed. I also discovered that it was in fact not maintained. Overall it lacks too much maturity for a serious game.
In the end, I decided to ditch it, because it was easier, and my proposals for help on GitHub never got any answer. It took some effort, but having my own engine based on OpenGL was the best choice in this case.
When it comes to Ebiten, I have only used the sound library called Oto, but overall my opinion of the whole package now is that it is well maintained and architected.
Now when it comes to choosing a language, I hesitated between:
- Go, which I had a lot of experience with and seemed good enough, even if the typing system is a bit too weak
- Rust, which I was (and still is) interested in, but had no experience, and unsure if it was worth it in terms of productivity (because of the additional time spent on worrying code, and the compilation time itself). Also, it didn't have game engines which seemed as mature as in Go at this time (I wish I had known that I would end-up with my own engine).
- C++, which is the industry standard, but on which I have very limited experience. Also, I just didn't want to bother with the header files and the compilation stack.
I chose Go, and too be honest it is a choice that I now regret, but also I have to live with it because I cannot afford a rewrite at this point.
Go certainly had a lot of productivity benefits, but also major flaws when it comes to game development:
- The lack of packages related to data structures. In games, we need a lot of specific sets, trees, queues, tries and maps, but those are almost non existent in Go. The best one is "gods", which still does not support generics. Overall it is always difficult to find quality and experienced packages, even for broadly used and fundamental algorithms.
- The fact that dependency cycles are handled on a package basis, and not per-class or per-file. This is a major source of headaches for video games, because contrarily to web servers, there are not a limited number of predefined layers: everything needs to depend on almost everything else, and Go makes it even worse in this case.
- The lack of data structures is made even worse by the native map, because it forcefully randomizes the iteration order, which causes a lot of bugs and makes it unusable 90% of the time. The authors wanted to prevent people from using it as if the key order was guaranteed, but their fix also broke the natural consistency of iteration order. This means for example that the drawing order of objects is different every frame, even when the data didn't change at all.
- When it comes to modding, there are not much options, because Go does not have a very easy or natural compatibility with FFI (cgo is awkward to use, and not really usable with dynamic linking), the native plugin package is experimental (and not even working in windows), and the support for WebAssembly is still quite poor (but getting better).