[martindbp]

Game dev in general has a much tighter feedback loop than most software. If you're leaking memory, you're doing that a hundred times a second. If your code is slow you get visual stuttering. If you want performant code you need to think about things like cache coherence, you can't use GC etc.

[piker]

I agree, but that's really true for questions like "does it run fast"? And those kind of arguably fit into the "legible" camp. Whereas "is it fun?" is a question less able to be formally tested and articulated. It's "illegible".

The tighter feedback loop that helps to answer that question comes from dogfooding.

[Pannoniae]

I agree with you for almost all of this, just a small nitpick:

GC isn't really incompatible with games, for the overwhelming majority of games, it's basically a non-factor in performance if you spend even the slightest amount of time on performance.

It's kind of similar to native code - don't allocate too much, reuse resources, don't leak them uncontrollably.

It's only a problem when you need guarantees (i.e. the game should never drop a frame) but basically no game fulfills that nowadays and it isn't a player expectation.

[gnulinux]

GC is ok as long as you aren't writing some factorio-like etc. Modern computers are perfectly fine doing shit ton of useless stuff 120 times a second without blinking an eye.

[martindbp]

If you're allocating stuff every frame you'll run into problems quickly. Sure, you can use an object pool or arena allocator, but then you're basically circumventing GC.

[yencabulator]

malloc often isn't fast enough for games either; arena allocators and ECS came to be for a reason.