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.
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.
"it all comes down to how you discipline yourself about writing code."
I don't think controlling one's own code is a problem. I'm more worried about the opportunities the language gives for Bob (my junior coworker) to slowly introduce all sorts of unclear cutting-edge language nonsense. Go is pretty good for this in my opinion.
That should be part of the team culture, similar to agreed upon coding conventions and naming standards. If there are no guidelines, Bob can screw up Go code just as bad as Perl.
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 :)
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.
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.
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.
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.
> 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.
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)