I've been writing a client for a virtual world in Rust, and I'm now one year in. A few comments.
The toolchain is solid. Nothing has broken.
The compiler's diagnostic messages are very good.
The concurrency model is usable. I was expecting more problems.
Single ownership with weak backlinks is too hard. You have to use Rc, which supports multiple ownership, and then much borrowing and unwrapping. Maybe some way to do single ownership with weak back references, with static analysis to detect safe cases?
There are important library crates that are stuck at version 0.x, and need a bit of polishing to make it to 1.0. It's not clear how that ever gets done, or by whom.
The 3D graphics situation is improving, but it's not solid yet. It's early to do serious 3D game development in Rust. Another 6 months to a year, I think, and it will Just Work.
One small vector and matrix library to rule them all. I'm using "glam", which is fine, although it had a breaking change last year which caused dependency problems. It's extremely helpful if all crates which use small vectors use the same format. Game development seems to be settling on "glam"; both WGPU and Bevy use it. Don't diverge, or you end up with conversion calls inside inner loops.
My experience is that the whole Rc and backlink issue is avoidable by just not using cyclic data structures in the first place, but if you work on games, that may be a lot harder than the kind of stuff I work on.
I think it can require a surprising amount of work to do. It did for Tokio.
Yes, it depends strongly on the problem space. RSS feed parser, no problem. Networking part of game code, no problem. Message handling part, no problem. Scene graph constantly being updated by multiple threads, big problem.
When you're displaying a big, dynamic 3D world, there's a lot of state involved. The problem would map well to a relational database, but that would be orders of magnitude too slow. So there are many links and hashes involved.
An ECS can be seen as conceptually similar to an in-memory relational database, with typically very good performance. It also fits well into Rust's paradigms, which is why a lot of Rust gamedev is putting an emphasis on ECS.
The whole point is to update the scene graph while the scene is being displayed. It takes one full CPU just to refresh the screen and drive the GPU. Updating is done from other threads. it's normal to keep four or five CPU cores busy doing this job. That's necessary to keep the frame rate up.
This isn't a web server, where async is good enough.