4 ms·

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

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.

baybal2 5y ago
Beware of Go. Google may use it to do the "Embrace Extend Extinguish" move. It might be type safe, but not ideologically safe. This is on top of Go being an unstable, immature language.
- 37ef_ced3 5y ago
  Go is very stable, and 12 years old.
nikki93 5y ago
Have you compared the performance and generated binary size of C vs. Go on WebAssembly?
- 37ef_ced3 5y ago
  For WebAssembly, use the TinyGo Go compiler: https://tinygo.org/ https://tinygo.org/
  - nikki93 5y ago
    Yeah the Go -> C++ compiler I linked from my other comment is pretty much overlapping with this idea. TinyGo is still a bit early afaict and also tries to exactly implement Go semantics but I'm kind of interested in extending / adapting it to my use case.
vladharbuz 5y ago
Has anyone benchmarked Go's garbage collector lately? I like a lot of stuff about Go, but a lot of my work is in video games and real time audio, and I am extremely hesitant to use a garbage collected language for those things.
- nikki93 5y ago
  I've been working on a Go -> C++ compiler pretty much mainly for this use case, that skips the GC and concurrency stuff -- https://www.reddit.com/r/golang/comments/r2795t/i_wrote_a_simple_goc_compiler_to_use_for_gameplay/ https://www.reddit.com/r/golang/comments/r2795t/i_wrote_a_si... -- Includes a demo video of a game I'm making with it and a built-in scene editor that uses reflection etc. Repo for compiler itself: https://github.com/nikki93/gx 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.
  - remexre 5y ago
    WebAssembly is notably a pathological case for _any_ stack-scanning GC, since the stack isn't addressable.
  - pphysch 5y ago
    > I know I can "do things to maybe cause the GC to run less" or such, but then that immediately starts to detract from the goal of having a language where I can focus on just the gameplay code. Did you try implementing pooling (e.g. sync.Pool) for game objects/entities/components/etc? How did that go perf-wise?
    - nikki93 5y ago
      I think the main thing is it starts to become a distraction from just writing the gameplay code. I don't have to implement the pooling stuff now that I have this compiler--naive / simple code tends to also start off with a high perf ceiling. But yeah if I did go further with the game in vanilla Go I might have to try the pool approach. Having worked on game engines with GC language runtimes (using Lua etc.) before, you always ultimately hit a perf ceiling due to lack of memory control and wish you could move out of it, but the runtimes don't give you a way to do that incrementally. 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.
einpoklum 5y ago
Go is not a "modern C". It may or may not be a swell language, but it differs fundamentally from C: 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.
- 37ef_ced3 5y ago
  I have been writing C for decades, but now I almost exclusively use Go. 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.
  - bachmeier 5y ago
    Honestly, I think D's betterC would be the right choice for someone that wants to keep writing C but wants modernized features. Go might be great for someone looking to replace C, but betterC is comfortable for someone that prefers to continue to write C.

baybal2 5y ago

Beware of Go. Google may use it to do the "Embrace Extend Extinguish" move. It might be type safe, but not ideologically safe. This is on top of Go being an unstable, immature language.

37ef_ced3 5y ago
Go is very stable, and 12 years old.

nikki93 5y ago

Have you compared the performance and generated binary size of C vs. Go on WebAssembly?

37ef_ced3 5y ago
For WebAssembly, use the TinyGo Go compiler: https://tinygo.org/ https://tinygo.org/
- nikki93 5y ago
  Yeah the Go -> C++ compiler I linked from my other comment is pretty much overlapping with this idea. TinyGo is still a bit early afaict and also tries to exactly implement Go semantics but I'm kind of interested in extending / adapting it to my use case.

vladharbuz 5y ago

Has anyone benchmarked Go's garbage collector lately? I like a lot of stuff about Go, but a lot of my work is in video games and real time audio, and I am extremely hesitant to use a garbage collected language for those things.

nikki93 5y ago
I've been working on a Go -> C++ compiler pretty much mainly for this use case, that skips the GC and concurrency stuff -- https://www.reddit.com/r/golang/comments/r2795t/i_wrote_a_simple_goc_compiler_to_use_for_gameplay/ https://www.reddit.com/r/golang/comments/r2795t/i_wrote_a_si... -- Includes a demo video of a game I'm making with it and a built-in scene editor that uses reflection etc. Repo for compiler itself: https://github.com/nikki93/gx 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.
- remexre 5y ago
  WebAssembly is notably a pathological case for _any_ stack-scanning GC, since the stack isn't addressable.
- pphysch 5y ago
  > I know I can "do things to maybe cause the GC to run less" or such, but then that immediately starts to detract from the goal of having a language where I can focus on just the gameplay code. Did you try implementing pooling (e.g. sync.Pool) for game objects/entities/components/etc? How did that go perf-wise?
  - nikki93 5y ago
    I think the main thing is it starts to become a distraction from just writing the gameplay code. I don't have to implement the pooling stuff now that I have this compiler--naive / simple code tends to also start off with a high perf ceiling. But yeah if I did go further with the game in vanilla Go I might have to try the pool approach. Having worked on game engines with GC language runtimes (using Lua etc.) before, you always ultimately hit a perf ceiling due to lack of memory control and wish you could move out of it, but the runtimes don't give you a way to do that incrementally. 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.

einpoklum 5y ago

Go is not a "modern C". It may or may not be a swell language, but it differs fundamentally from C: 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.

37ef_ced3 5y ago
I have been writing C for decades, but now I almost exclusively use Go. 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.
- bachmeier 5y ago
  Honestly, I think D's betterC would be the right choice for someone that wants to keep writing C but wants modernized features. Go might be great for someone looking to replace C, but betterC is comfortable for someone that prefers to continue to write C.