The main problem which global state introduces, is making the bad assumption that there will only be one example of a given sort of data.

In games, that's a safe assumption for many parts of the system, since you're definitely only going to be running one instance of the game world at a time. So making that state private just means you have to pass around references to it on the stack, and keep track of what you're doing.

Classic webcrap is near-stateless, with state in the database only. That way, any server in the farm can handle the next client request. Games have a consistent world to maintain in memory. Sometimes a really big consistent world.

I feel like this is an underrated sentiment. A lot of Rust’s design decisions (lack of inheritance, borrow checking, immutability by default) are complete non-issues when you’re reading a JSON string into some business struct or an enum and then serializing it back out to a DB again. Everything can be flat data types and functions can be pure and stateless.

But not if you actually have to keep things around in-memory. Then all the sudden your functions can’t be pure, you have to add additional parameters to each method to account for additional state, and you can’t design flat structs anymore since you have many different object types and they have to go somewhere and you can’t just declare N variables line by line. So you have to grapple with the limited definition of trait objects, or non-extensible enums, or throw everything out and use Any. It gets complicated.

Maybe games are more likely to lean on global in memory state, instead of the global state being in a database.