> Someone else set out to do something similar in C#/Unity and had something going in less than two years.
But in that case doesn't the garbage collector ruin the experience for the user? Because that's the argument I always hear in favor of Rust.
But in that case doesn't the garbage collector ruin the experience for the user? Because that's the argument I always hear in favor of Rust.
Even without the incremental GC it's manageable and it's just part of optimising the game. It depends on the game but you can often get down to 0 allocations per frame by making using of pooling and no alloc APIs in the engine.
You also have the tools to pause GC so if you're down to a low amount of allocation you can just disable the GC during latency sensitive gameplay and re-enable and collect on loading/pause or other blocking screens.
Obviously its more work than not having to deal with these issues but for game developers its probably a more familiar topic than working with the borrow checker and critically allows for quicker iteration and prototyping.
Finding the fun and time to market are top priority for games development.
Anything with a graphical shell is probably better written in a GC'd language, but I'd love to hear some counter-arguments.
If it’s a really logic-intensive game like Factorio (C++), or RollerCoaster Tycoon (Assembly), then I don’t think you can get away with something like Unity.
For simpler things that have a lot of content, I don’t think you can get away with Rust, until its ecosystem grows to match the usual game engines of today.