Comment by paulddraper
9 months ago
Go is infamous for its gc latency spikes, which is the thing that games cannot tolerate.
Though 1.18 helped a lot, you'd have to do some major persuasion to game devs that Go's gc is the kind of thing they'd want in their game.
---
EDIT: Not sure the downvote, Go is know for its (historically at least) unsuitability for RTC or game dev.
I’ve heard that go has very low latency gc, i haven’t heard of it having spikes
The problem with Go is its inadequate FFI, which is important for gamedev which tends to be FFI and syscall-heavy due to embedding another gamescript language and/or calling into underlying rendering back-end, sometimes interacting with input drivers directly, etc.
Which is why C# has been chosen so often (it has performance not much worse than C++ (you can manually optimize to match it), zero or almost zero-cost FFI, and can also be embedded, albeit with effort).
There are also ways to directly reduce GC frequency by writing less allocation-heavy code, without having to resort to writing your own drop-in GC implementation (which is supported but I haven't seen anyone use that new API just yet aside from a few toy examples, I suppose built-in GC is good enough).
The overhead for Go in benchmarks is insane in contrast to other languages - https://github.com/dyu/ffi-overhead Are there reasons why Go does not copy what Julia does?
1 reply →
Your comment is down voted because it is false. Go is not "infamous" for gc latency spikes.
It is probably true for game engine dev, but not generally true for game dev, which is a vast field and not as computationally demanding as many imagine. I believe Go's unwillingness to be less strict about some (non-type) semantics would be a bigger problem for game devs than GC.
That's true. Go ain't C4 (JVM), ORCA (Pony), HiPE (Erlang/OTP BEAM), or CLR (C#). The JVM and CLR runtimes have been beaten on for years at immense scale in server-side business settings. I wished Go supported embedded work (without a GC), had an alternative allocator a bit more like Erlang's, and had alternative implementations that transpiled to other languages, but it doesn't. Ultimately, I left when zillions of noobs poured in because it was seen as "easy" and started wasting my time rather than searching for answers themselves.
If performance were such a huge concern, I don't see any valid resistance to Rust that completely lacks a GC and makes it easy to call C code other than "it's something different", "there's too much hype", or "I don't like it". Recent development tools like RustRover make is really damn easy to see whats a move value or a borrow, debug test cases, run clippy automatically, and check crates versions in Cargo.toml. Throw Copilot in there and let it generate mostly correct, repetitious code for you.