Even though I’m not a game developer that project makes me really happy. I think it does an excellent job at being a Go project that largely sticks to the Go philosophy while making some practical decisions that might be considered going against it.
I know there’s trends and Go (and Rust and Zig and others) are hip right now, so lots of people currently use Go, but I always have to think that thess are probably the people complaining that Go doesn’t do things like some other language.
Given that this is something I have seen in game “engines” a lot too (with web frameworks being the other big offender) I just really enjoyed watching Ebiten developing like it did, sticking to being Go b rather than becoming it’s own thing (framework), barely resembling regular Go development. I’m sure most people here can think of languages and projects that are only “technically” still using the language/implementation they are made for.
A lot can be learned from Ebiten’s example. It seems to have made great choices between being perfect and practical. I also think it’s nice where the the boundary between C(++) and Ebiten (and Oto) is drawn. It’s just a joy to follow the project’s development, and as mentioned I do that without even developing games, even though it really made me itch to try and do so some day.
So in short: Great work!
The presentation shows that the garbage collector in Go is not a problem when developing games.
Well, not really. It shows that the GC isn’t a problem when developing relatively technically simple 2D games. That’s not exactly news.
Being able to stop it and start it when you want, or create a pool of memory that is manually managed, should make memory alloc/free performance no worse than in C and C++.
The presentation doesn’t demonstrate this from what I can see. It shows various tricks to work around the GC, but not that it makes the situation no worse than C and C++.
Right out stopping the garbage collection is not a trick, though. It just puts Go in the same category as C and C++.
I’m a total Go apologist and I wish this was true, but it isn’t. When you invoke runtime.GC() it checks the entire heap, it’s not just doing work for the objects that do need to be collected as manually freeing the objects would, it has to do a bunch of work to determine which objects need to be collected; that entails doing a lot of work around objects that don’t need to be freed, which is work that is avoided entirely with manual memory management. Running the entire garbage collector is mark and sweep, but freeing stuff yourself is just sweep; the whole “crawl the entire heap” portion of the equation is eliminated. Of course, the tax you pay for that is you might get it wrong in some way, unless you have some mechanism for compile-time checking of memory safety built into the language and its compiler.
You could allocate all the memory you think you need, stop the garbage collector, allocate additional memory as needed while the program is running, free memory as needed while the program is running and then at the end of the program start the garbage collector again, though.
Big fan of Ebiten and Hajime Hoshi, an incredibly nice person who for me embodies OSS.