Why can’t you use
stdfor game dev?
(I speak as a hobbyist who watches a lot of game dev talks and tinkers with stuff in his garage but who doesn’t work in the AAA space or anything like that)
The short answer is that you can use std for some game dev, but not all of it.
The long answer is that among the many ways to break down and categorize games there's one way to split things that I'll focus on for the moment. While attempting to be charitable to everyone involved, we'll call it "developing a game using an engine" vs "developing a game engine".
If you are developing a game using an engine then the non-rust version of that story is gonna be Unity (C#) or Game Maker (Pythonic scripting lang?) or RPG Maker (Ruby?) or things like that. The rust version of that story is things like Piston or GGEZ. Might be 2d, might be 3d, either way it probably doesn't push the hardware to its limits with complex physics and other background computation. There are plenty of amazing games developed this way, I'm sure we can all think of our own favorite examples. This is usually done by people who are a little lighter on the programming side of things and that are better at the game design and game aesthetic sort of stuff. A lot of them are even first time devs with just a strong vision and consistent art, and I love it. Rust should cater to these people as much as possible, and these people would doubtlessly be using the std libraries along with all manner of crates from our ecosystem.
The other case is when you are developing a game engine. Now it might be just for one game that runs on and on for a decade plus of development (eg: Dwarf Fortress), or it might be something that's used on several projects and expanded over time while staying focused towards a type of game (eg: the Clausewitz Engine), or it could be a "general purpose" engine that grows over time to fit all sorts of needs (eg: the Unreal Engine). They're pretty much written in C++, and they're pretty much written by people who some might consider a little strange. You want absolute control at all times. If you can't have absolute control at all times it better be because the OS itself won't let you have it, and no other reason. This means that if you're going to use a lib at all (which, honestly, maybe you wouldn't, because there's a lot of Not Invented Here to go around in game dev), it better be one that serves you exactly how you want. It should take the memory you give it and not allocate. It should run on the threads you specify and not spawn workers of its own. It should generally work exactly like the code you would have written yourself. We're talking about the kind of attitude where people maybe don't fully trust libc to get it right.
If you want into the low level game dev space you're competing with C/C++, and you're sometimes trying to convince people who've been doing C/C++ for 10 or 20 years. They don't usually have memory problems. This can happen, but usually they've got other kinds of problems. They have compilation speed problems. They have expression problems. They have combinatorics problems. They have plain old math bugs lurking in rarely used code branches. Rust can help with some of these things. I've personally spent the last few weeks converting a C++ project to Rust by hand, about 8000 lines so far, and I'm seeing the sorts of warts it has simply by being written in C++, and that are fixed fairly trivially in Rust. I'm sure other C++ code bases have their own warts that Rust can fix too. We can absolutely improve people's quality of life, but we can't do it by saying things like "oh, also, I'm gonna take away some of your control and allocate on my own some of the time". Low level game dev is in some ways like embedded dev, because often you want to squeeze the program down to fit on a tiny device like a phone or a handheld system, or because your program wants to grow so huge that even a desktop PC is "small" for its purposes.
One final note is that anything available to core is naturally also available to std, but the reverse is not true, so I would say that things should be core when possible simply as a matter of language design, regardless of programming domain.