Notes after a year of Rust

[John_Nagle]

I've been writing a client for a virtual world in Rust, and I'm now one year in. A few comments.

Basics

• 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.

Game-specific issues

• 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.

[alice]

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.

@John_Nagle

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.

I think it can require a surprising amount of work to do. It did for Tokio.

[John_Nagle]

@alice

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.

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.

[geeklint]

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.

[H2CO3]

@John_Nagle

Scene graph constantly being updated by multiple threads

Can't you delegate updates to a single thread and use in-process message passing through a synchronized queue to avoid this problem?

@John_Nagle

The problem would map well to a relational database, but that would be orders of magnitude too slow.

I think you might be interested in @2e71828's thesis.

[gretchenfrage]

@John_Nagle

One small vector and matrix library to rule them all.

I do really want this, but for the mean time, mint exists to try to make interoperability easier.

[John_Nagle]

@H2CO3

Can't you delegate updates to a single thread and use in-process message passing through a synchronized queue to avoid this problem?

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.