> The library support [in Go] for games is quite poor,
I'd like to know the author's familiarity of Go libraries. Perhaps he's unaware of what does exist and makes false claims, or perhaps he's saying accurate statements and just has really high standards.
I help maintain many of the Go libraries/wrappers for games, so I might be biased, but I'm happy with what is available. Almost more so than when I was using C++, because Go packages can be made go-gettable and very easy to include and distribute, unlike with C++.
I've also not hit GC problems so far, but arguably my games are just not demanding enough yet.
I'd like to pick your brain in real-time, but, in a nutshell, how far do you think Go game ecosystem is from something like Corona, LibGDX, Haxe? Have SDL, OpenGL wrappers stabilized, are there native ports? Any frameworks that might be considered close to production-ready?
OpenGL libraries have definitely stabilized and have been that way for multiple years now. GLFW 3 wrapper is go-gettable (some years ago, it required manual installation of the C library separately, now you just go get it). I don't use SDL so I don't know much about it.
I don't know if there are complete frameworks or engines that are finished, but there are some works in process.
I'd like to know the author's familiarity of Go libraries. Perhaps he's unaware of what does exist and makes false claims, or perhaps he's saying accurate statements and just has really high standards.
I help maintain many of the Go libraries/wrappers for games, so I might be biased, but I'm happy with what is available. Almost more so than when I was using C++, because Go packages can be made go-gettable and very easy to include and distribute, unlike with C++.
I've also not hit GC problems so far, but arguably my games are just not demanding enough yet.