If you want a modern C, use Go.
Unless you need maximum performance (SIMD, GPUs, etc.) you should use a developer-efficient, productive language.
Well-written Go executes almost as fast as C, and you will be more productive as a programmer.
Unless you need maximum performance (SIMD, GPUs, etc.) you should use a developer-efficient, productive language.
Well-written Go executes almost as fast as C, and you will be more productive as a programmer.
1. Go is a garbage-collected language, C is not.
2. Go is a single-company-managed language, while C is managed by an international standards committee within ISO. You might not care about this difference, but its quite significant w.r.t. how future language developments happen.
3. C types are intentional, Go types are extentional ("structural typing").
These fundamental differences are not cases of one language being superior, or further advanced, than the other - they're about going in different directions.
What I mean is that if you like C99, you will probably like Go. Go can be understood as a modernization of C that doesn't abandon C's simplicity but adds a few important facilities that C lacks.
Go obviously derives from C. It's a very C-like language. It makes sense to view Go as an enhanced C that makes slightly different trade-offs and that is applicable to a slightly different set of purposes.
Repo for compiler itself: https://github.com/nikki93/gx (no README.md etc. yet, will be getting to that when I next have a chance (it's a side project)). It just takes around 1500 lines of Go thanks to the parser and typechecker in the standard library.
Go's perf was definitely non-trivially bad for me on WebAssembly.
Did you try implementing pooling (e.g. sync.Pool) for game objects/entities/components/etc? How did that go perf-wise?
Ultimately in the game scenario the GC is actually just ... not helpful. Game logic code already explicitly handles lifetimes to some degree (eg. when this entity collides with that one, destroy it, etc.) -- emergently deciding when to free things based on references is usually not what you want. You do want it for resource management (like a texture cache), but it actually makes sense to kind of roll that on your own and adapt it to the game. So having a GC and then fighting it just sounds like an ill-fitted solution.
In a well designed game engine, you will only need to implement it a handful of times (if that) to cover 99% of the hot code. Certainly not something to need to do for each class of game object.
This is on top of Go being an unstable, immature language.