Makes me wonder why Rust isn't popular with game devs. Wouldn't Rust's borrow checker and resource management at compilation time make most of the described memory reclaiming issues obsolete?
Too new to have a mature gamedev ecosystem. I only finally started tooling around with rust when someone tweeted they'd gotten it working on the PS4, but that still puts me in the early adopter boat.
> Wouldn't Rust's borrow checker and resource management at compilation time make most of the described memory reclaiming issues obsolete?
No. It might help you verify that the systems you're building to tackle these problems are correctly implemented, but it's not going to help you tackle the fundamental problem of e.g. "this game has more 'active' data than we actually have the RAM for".
In theory, this is the problem that virtual memory and page files solve. In practice, occasional small 50-100ms stalls which might be acceptable for a text editor are really nasty for a real time twitch and flow based game. 60fps gives you a frame budget of 16ms - if you want your animation to remain at a fluid 60fps, your absolute max frame time is 16ms.
So, games will end up writing their own memory management systems to e.g. partially load and unload textures at runtime. They'll build in knowledge of your level layout to try and prefetch textures before they're actually necessary based on where the player is moving, so they're available by the time the game needs them - and they might chose to render using a lower resolution version of a texture that was kept in memory if the high resolution version wasn't loaded in time instead of stalling the game.
http://www.pcgamer.com/new-details-and-screens-from-stardew-...
In Rust:
https://www.reddit.com/r/rust/comments/78bowa/hey_this_is_ky...
Another one is that borrow checker. Games are heavily multithreaded since X360. Game state + game assets = huge pile of data shared across threads. Borrow checker in Rust makes it harder to write parallel code that operates on that large shared state. For small state and/or plenty of RAM you can afford making copies but games can’t afford that. Sure Rust brings value here by eliminating a class of bugs, but for game clients (servers are different story) the optimal safety/resource tradeoff is at another place than e.g. for a web browser.
Finally, games often use many third-party libraries and frameworks (sometimes called middleware), and due to historic reasons majority of those are C or C++ libraries.
In game engines, these pieces of memory often need to be mutable by multiple threads. E.g. see this old Intel article for a high-level overview how it might work: https://software.intel.com/en-us/articles/designing-the-fram... Now with DX12 / Vulkan it became even worse, because with them we no longer have _the_ render thread.
Sure, doing that the dangerous C++ way can introduce bugs. But the risks are different.
If you’re working on a web browser (that’s what Rust was created for), the worst thing that may happen, a compromised web site you’re viewing (maybe even by accidentally clicking a link) may infect your PC, steal all your data and turn your PC into a botnet node.
Most games can’t technically fail that bad, due to the following reasons (1) Most games don’t allow users to create content, only the developers do (2) Modern console games work in a hardware-assisted hypervisor (3) Some platforms even verify digital signatures of all the content they load.
Games often create their own allocators for a variety of reasons (specialized allocation strategies for speed or fragmentation reasons, adding debug statistics, enforcing memory budgets for (sub)systems, etc.) - although that's not terribly OS or language specific.
That is how they moved from Assembly into C, C into C++, adopted Objective-C, adopted C# in their tools, accepted external middleware like Unreal or Unity.
So until one of the big desktop or console owners releases an SDK where Rust is the language, they will hardly adopt it.
Sure a few indies might do it, but it will be a blip on the radar of the usual Game Developer Conference attendees.