Go does surprisingly well at keeping GC freezes to a minimal in a way that you're unlikely to notice... C# has gotten a lot better since the core split as well. That said, there's a lot that comes down to how a developer creates a game.
I was added late to a project working on a training simulation engine, similar to games, where each avatar in the game was a separate thread... man, the GC pauses on the server would sometimes freeze for literally 10-15s, and it was not good at all. I refactored it to use an event-loop model and only 2 other threads, which ran much better overall. Even though it wasn't strictly a game itself, the techniques still matter. Funny how running through a list of a few hundred things is significantly better than a few hundred threads each with their own timers, etc.
> C# has gotten a lot better since the core split as well.
It has improved but the majority of games using C# are using Unity which does not use .NET (Core). It uses Mono or IL2CPP specifically with the Boehm GC so it performs significantly worse than .NET and even standalone Mono (SGen GC).
> Funny how running through a list of a few hundred things is significantly better than a few hundred threads each with their own timers, etc.
State machines are not in fashion. Exposed event loops are not in fashion. Most frameworks do their damnedest to hide those components.
As for GC freezes, if you're doing a game like project you can always just allocate a few huge arrays at startup and reuse those with no deallocation/allocation in most garbage collected environments.
It's not what people mean when they say GC though, especially in reference to games, where you care about your peak frame time more than about your average frame time.
Reference counting can also have very bursty performance. Consider what happens when you decrement the last reference to an object which is the sole remaining reference to an entire large tree of other objects. This will trigger a whole cascade of subsequent decrements and deallocations, which can be arbitrarily large.
Of course, you might say, "Well, sure, but your reference counting implementation doesn't need to eagerly deallocate on dereference." That's true! You can write a ref counter that defers some of those deallocations or amortizes them across multiple operations.
And when you do that, now you really do have a garbage collector.
You should watch some of the more recent Gamers Nexus videos... the average frame pacing counts for a lot, and they're making a concerted effort to show this, as it does represent the level of "jank" in games very well.
More broadly than frame pacing, https://www.youtube.com/watch?v=Fj-wZ_KGcsg is a recent example of one of _many_ interviews going back years on why both frame times and frame rates are all flawed for explaining why some games feel smoother/lag more than others (there are GN videos dating back to 2016 on the subject)
I haven't dug deep enough into C# to say this with certainty, but I believe later C# versions allows you to do enough manual allocation to "almost" get around the garbage collector. As well as new calls to try and nudge the GC away from hot paths.
You need to be very disciplined to pull this off, though. LINQ is basically off limits, for example. And of course, Godot's C# is likely much older than these modern techniques to begin with.
That's good to know. So it probably has the capability if you really wanted to dig in.
But that effort on an active engine would quite a long time to comb through. Really comes down to if a highly invested contributor wants to push it through and gets the go ahead.
Other languages that bind into the engine do this too, (C++, SwiftGodot, Rust-Godot)
C# obviously does, Miguel de Icaza actually started SwiftGodot because he (ironically) ended up hating GC pauses after promoting C# for so long