Yes-- the one area where a pure-Go solution is weak happens to be 3d game development.
The obvious solution is to use C/C++ library bindings (raylib, opengl, etc). Yes-- you pay a tax for making calls into the C world and it becomes a lot harder if not impossible to do single binary builds. It also complicates native ports to other platforms like Nintendo, etc.
It's not impossible, just complicated. Luckily, I don't do 3d game development.
Not sure if you're being intentionally cheeky by pointing out a use case one wouldn't use Go for but will answer anyway.
A language with a GC (like go) typically isn't a good fit for a 3d engine. Almost all serious engines are C++, at least for the core code, for that reason.
> pointing out a use case one wouldn't use Go for but will answer anyway.
The thread is about using Go everywhere and I make games so I'm asking about it.
Unity and Godot have C# scripting which most game code will be in. Unreal has garbage collecting for game assets. GC is just another tradeoff to work with and certainly not a deal breaker for games.
I'm mostly curious about whether someone has done the work to integrate goroutines with a 3D engine in a performant way as typical techniques require a lot of synchronization with native threads that seem at odds with Go's design. But I'm curious to see it done.
