4 ms·

Life is barely long enough to get good at one thing so you should choose your thing wisely. That's wisdom I've held for quite some time. Coincidentally, I chos

Life is barely long enough to get good at one thing so you should choose your thing wisely. That's wisdom I've held for quite some time. Coincidentally, I chose Go as my language of choice as well. The factors that led me to that choice were many, but to highlight some: - incredible standard library - simple to read and write - single static binary builds (assets included, like html/images, etc) - don't need a container (my binary is the container) - can be used anywhere (webdev, desktop apps, gamedev, embedded, etc)

jayd16 2y ago
What game engines use Go?
- jayd16 2y ago
  I should say what 3D game engines use Go?*
  - throwawaythekey 2y ago
    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.
    - jayd16 2y ago
      > 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.
  - bitbasher 2y ago
    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.
sedatk 2y ago
I chose C# for the same reasons. It's probably easier to make C# unreadable than Go due to plethora of features, but it all comes down to how you discipline yourself about writing code.
- mats852 2y ago
  https://github.com/bflattened/bflat https://github.com/bflattened/bflat
  - jayd16 2y ago
    Single file AOT is now officially supported by base dotnet.
    - neonsunset 2y ago
      bflat has somewhat different set of goals and offers "zerolib" and "uefi" runtime target flavours. Its author is also working on the official NativeAOT, which bflat builds on top of :) While we're at it, it's impressive how much NativeAOT has improved within just 2 releases or so: https://migeel.sk/blog/2023/11/22/top-3-whole-program-optimizations-for-aot-in-net-8/ https://migeel.sk/blog/2023/11/22/top-3-whole-program-optimi... There are other niceties like dehydrated binary sections, metadata compression, linker that is deeply aware of the type system, etc. to keep the binary size scalable as you keep adding dependencies. I'm seeing even smaller sizes with .NET 9 preview.
- christophilus 2y ago
  My main beef with C# was the culture. I spent around 15 years building stuff in C# (since 1.0), and absolutely loved the language. But, man. The Microsoft shops were so full of Kool-Aid drinkers, and there was so much enterprisey crap that often came along with that. I miss C#, but I don't miss the culture.
  - deleted 2y ago
    [deleted]
bb88 2y ago
I appreciate the Rust approach where Rust <-> C and Rust <-> Python get along really well together. They really thought about interoperability with existing infrastructure. Java wanted everyone to rewrite everything in Java because that was easier than to interface with the existing libraries on the OS.

jayd16 2y ago

What game engines use Go?

jayd16 2y ago
I should say what 3D game engines use Go?*
- throwawaythekey 2y ago
  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.
  - jayd16 2y ago
    > 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.
- bitbasher 2y ago
  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.

sedatk 2y ago

I chose C# for the same reasons. It's probably easier to make C# unreadable than Go due to plethora of features, but it all comes down to how you discipline yourself about writing code.

mats852 2y ago
https://github.com/bflattened/bflat https://github.com/bflattened/bflat
- jayd16 2y ago
  Single file AOT is now officially supported by base dotnet.
  - neonsunset 2y ago
    bflat has somewhat different set of goals and offers "zerolib" and "uefi" runtime target flavours. Its author is also working on the official NativeAOT, which bflat builds on top of :) While we're at it, it's impressive how much NativeAOT has improved within just 2 releases or so: https://migeel.sk/blog/2023/11/22/top-3-whole-program-optimizations-for-aot-in-net-8/ https://migeel.sk/blog/2023/11/22/top-3-whole-program-optimi... There are other niceties like dehydrated binary sections, metadata compression, linker that is deeply aware of the type system, etc. to keep the binary size scalable as you keep adding dependencies. I'm seeing even smaller sizes with .NET 9 preview.
christophilus 2y ago
My main beef with C# was the culture. I spent around 15 years building stuff in C# (since 1.0), and absolutely loved the language. But, man. The Microsoft shops were so full of Kool-Aid drinkers, and there was so much enterprisey crap that often came along with that. I miss C#, but I don't miss the culture.
- deleted 2y ago
  [deleted]

bb88 2y ago

I appreciate the Rust approach where Rust <-> C and Rust <-> Python get along really well together. They really thought about interoperability with existing infrastructure. Java wanted everyone to rewrite everything in Java because that was easier than to interface with the existing libraries on the OS.