He was very approachable and friendly when I was toying with game development in Go.
I should get back to finishing that game in Ebiten. The tooling alone puts a smile on my face.
C++ is probably a must if you one writes large games and/or performance critical ones (regarding "high performance"/low level languages, Rust libraries are immature).
Scripting languages (e.g. Python/PyGame) can be a good (quick) way to start and experiment. But readability falls very quickly when complexity grows (e.g. difficult to interpret inheritance tree), so at some point one may easily feel the need to switch to a statically typed language.
Regarding algorithms, a very common beginners book is "Game Programming Patterns", which is also available for free in HTML: https://gameprogrammingpatterns.com/contents.html.
Naturally if you aren't looking into getting into the industry, rather having fun at coding games, anything that can do graphics and sound will do.
- Lack of generics(coming very soon) was a huge problem for a long time and resulted in masses of duplicated code, and shonky reimplememtations rather than battle tested reusable implementations.
- Lack of sum types, which is particularly frustrating with go's error handling model (which I happen to be a fan of, mostly). The state of a return value depends on another return value in many cases. There is nothing in the language stopping me from using the value returned from a function that has returned an error. Even c++ has a (half baked) solution for this with optional.
- go's error handling has a major issue; it forces my model to be able to represent invalid state (see above). Because go doesn't let me have a sum type, I'm forced to return a "valid" return value alongside the error value, which means that state has to be representing in my code.
- repetition. Contrary to best practices in every other programming language, the advice given for go on so is frequently "its not that much work to implement the X yourself". Now instead of using an existing well supported library I'm maintaining my own X.
- cgo. Performance is terrible, its completely unique compared to every other FFI style system (e.g. see dotnet), and it doesn't work with MSVC.
> that took into account & understood the practical tradeoffs Go is making.
Just because the language had made decisions because of tradeoffs doesn't make it immune from criticism. If it's OK to criticise c++ for not breaking backwards compatibility (vector<bool> comes to mind), it's OK to criticise go for its shortcomings.
For example, I may dislike a language simply because it has no significant white-space: I just like a programming language to display nicely, for my definition of "nicely". I do understand practical tradeoffs of significant whitespace, yet I still like it: those are not in opposition with each other.
I get that feeling too but I have no experience with game development. I wonder what reasons you think so?
Nice to see Hoshi's work shared here.
The author also explicitly stated that he did not expect major work to upgrade to a new Go version in https://ebiten.org/blog/native_compiling_for_nintendo_switch....
