[59nadir]

I suspect Nim would be much, much harder to wrangle for games than Zig (or easily the best of the bunch: Odin) since it doesn't make enough things clear at all in terms of allocation and only allows indirect control of allocation and deallocation.

I wouldn't necessarily prefer Nim for any of the things you listed but this doesn't have the same argument as for games with Odin (which has great tools and libraries for making games as well as gives a much better overview of important things you'll have to care about for making them in terms of performance, etc.).

Rather, it's because I've found that Nim belongs with the other languages that think that complexity can be managed by being hidden well enough, which I've found is simply not the case when something actually needs to be debugged or you need to understand the behavior of the program.

Hiding/ignoring allocation errors, not making allocation explicit, not making deallocation explicit, etc., makes for a much worse time actually understanding what's going to happen. Adding tons of GC options like alternative GC implementations isn't going to fix it and this new one is really just another example of trying even harder to hide complexity.

I think the ultimate irony of these languages that have magical features like move semantics is that they do some of those things in the name of performance but in practice many of them are so complicated to write well-performing code in with these space technology features and non-obvious behavior that the end results are worse than much, much simpler languages. I've also found that these languages' development cycles (for the end user) isn't that much longer than the space tech ones because there is ultimately much, much less to use in them so people end up just writing the actual code instead of trying to wrangle all of the magic.

[xigoi]

Many game developers want to focus on writing games instead of fighting a memory allocator. Unless you're making a 3D game with realistic graphics, you don't need every last bit of performance.

[59nadir]

No one needs to be fighting allocators; they are far less inhibiting and pose less of an issue than GC or RAII will in the vast majority of cases. They're far easier and simpler to deal with on the whole as well. You're always interfacing with memory management somehow and the implicit way is usually much harder to work with overall. The idea that having an allocator and explicitly working with it is for "that last bit of performance" is a bit disingenuous, you're usually losing far more than that with implicit allocation and deallocation. On top of that you simply inherently have a harder time understanding the behavior of your program.

[xigoi]

Manual memory management is one more thing to care about instead of the actual logic. With automatic memory management, you don't need to think about memory at all; what could be simpler?

[59nadir]

Easier in the best case and much harder in the worst, when your lack of thinking is an issue (which it definitely will be unless you're prepared to use more of the machine for no reason). Simplicity is not about what's easier to use, it's about how you interface with something, how simple and straight forward that interface is to use, how many things are implicitly or explicitly affected by that thing, and so on. Automatic memory management usually implies an assumption that allocations can't fail, memory is infinite, etc., so the assumptions and complications are many. It also adds more code you didn't write and have no direct control over, which complicates your problem solving in many ways.

GC or other automatic memory management is only easier if you have absolutely zero care for resource usage. RAII will oftentimes lead to single allocations and deallocations, for example, unless you take care to not have it be so, which is an immense waste of resources.

It's fine if you don't care and you know that that's going to produce slow, bad software, but let's be honest about that instead of saying you can not care and everything will be fine.