That's a good article. He's right about many things.

I've been writing a metaverse client in Rust for several years now. Works with Second Life and Open Simulator servers. Here's some video.[1] It's about 45,000 lines of safe Rust.

Notes:

* There are very few people doing serious 3D game work in Rust. There's Veloren, and my stuff, and maybe a few others. No big, popular titles. I'd expected some AAA title to be written in Rust by now. That hasn't happened, and it's probably not going to happen, for the reasons the author gives.

* He's right about the pain of refactoring and the difficulties of interconnecting different parts of the program. It's quite common for some change to require extensive plumbing work. If the client that talks to the servers needs to talk to the 2D GUI, it has to queue an event.

* The rendering situation is almost adequate, but the stack isn't finished and reliable yet. The 2D GUI systems are weak and require too much code per dialog box.

* I tend to agree about the "async contamination" problem. The "async" system is optimized for someone who needs to run a very large web server, with a huge number of clients sending in requests. I've been pushing back against it creeping into areas that don't really need it.

* I have less trouble with compile times than he does, because the metaverse client has no built-in "gameplay". A metaverse client is more like a 3D web browser than a game. All the objects and their behaviors come from the server. I can edit my part of the world from inside the live world. If the color or behavior or model of something needs to be changed, that's not something that requires a client recompile.

The people using C# and Unity on the same problem are making much faster progress.

[1] https://video.hardlimit.com/w/7usCE3v2RrWK6nuoSr4NHJ

As a game developer for about two decades, I've never considered Rust to be a good programming language choice.

My priorities are reasonable performances and the fastest iteration time possible.

Gameplay code should be flexible, we have tons and tons of edge cases _by design_ because this is the best way to create interesting games.

Compilation time is very important, but also a flexible enough programming structure, moving things around and changing your mind about the most desirable approach several times a day is common during heavy development phases.

We almost never have specifications, almost nothing is set until the game is done.

It is a different story for game engines, renderers, physics, audio, asset loaders etc. those are much closer to system programming but this is also not where we usually spend the most time, as a professional you're supposed to either use off-the-shelf engines or already made frameworks and libraries.

Also, ECS is, IMHO, a useful pattern for some systems, but it is a pain in the butt to use with gameplay or UI code.

> Rust gamedev ecosystem lives on hype

I've been saying this for years. I've tried to get into Rust multiple times the past few years and one of the things I've tried was gamedev with Rust (specifically the library ggez when it was still being worked on, and a little bit of Bevy). I admittedly never got far, but I gave it a solid shot.

My experience was instantly terrible. Slow compile times and iterations, huge package downloads (my project folder was roughly 1gb for a simple 2D project), and of course Rust itself was difficult to get into with lifetimes and having to wrap and unwrap my variables constantly and getting into wrestling matches with the borrow checker.

I kept telling myself that everyone loves Rust and the community loves to rave about anything Rust-related and maybe I just don't get it, but it took some time to realize that no... It's just a terrible choice for it. I even tried to make UI with eGUI and was still miserable. Rust is a systems programming language but the community is trying to convince everyone should be used for general purpose stuff.

And my other biggest problem is that they keep painting other non-Rust things as being fundamentally flawed for not being Rust. "It's not memory safe" is the biggest one thrown around, but when was the last time memory safety was actually a big problem in games? Unity uses C# which is garbage collected, Godot uses its own scripting language which makes it nigh impossible to leak memory, Unreal AFAIK has its own tools that makes memory management trivial. Rust game development feels like a solution looking for a problem to fix.

I am curious about Bevy when it becomes mature and has its own editor, but for now I'm just not convinced gamedev with Rust will ever take off.

I've done hobby gamedev in Bevy/Rust, Godot/C#, and Unity C#.

It's honestly somewhat baffling to me that folks will choose Rust for gamedev right now. The state of the open sourced tools are just not there yet, especially when compared to Godot, and at the same time these games are running on PC hardware which tends to get faster every year.

Also for ECS... one thing I tended to realize is that when developing a game, pigeonholing everything into an ECS can seriously tend to get in the way. A lot of (efficiently written) game code is best handled in an infrequent event-driven way.

An ECS backed game engine like Bevy can make big mobs more efficient, but few games will actually leverage this effectively for fun gameplay and at the same time modern PCs are fast as hell.

I think about Starcraft from 1998, created when virtually all PCs only had one core, and its 200 unit per faction cap. Blizzard hasn't increased this cap because it doesn't necessarily make the game more fun. Now should a gamedev today, 26 years later, making a 2d isometric game for the PC be worried about performant multithreading????

Allan Blomquist's tooling demo they mention is incredible, go watch it:

https://www.youtube.com/watch?v=72y2EC5fkcE

Really sells the value of having a tight developer feedback loop: it shows hot reloading for code and graphics, a reversible debugger, live profiling with flame graphs, a data inspector with data breakpoints, time travel inspection with a scrub bar, session sharing and replay with the same scrub bar and direct links from the call stack to a breakpoint, and more.

Above the many niggles they had with Rust itself, this greatly helps me understand why Rust left them wanting more from their working environment. They say they've switched back to Unity with https://hotreload.net/ to try to capture some of that, and now I see why. (It's a shame that hot reloading tooling in Rust wasn't ready for them yet, but I see why they've moved on instead of waiting/contributing.)