Well, here we are, a year after I wrote "Game dev in Rust, some notes on the mess." Things haven't changed much. 
I'm still using the Rend3/WGPU/Vulkan graphics stack. It works reasonably well at this point. 
Notes: 

Se…

Lobsters is a community-driven platform for sharing and discussing links to articles, tutorials, and projects related to technology and programming. Readers can learn about a wide range of topics, from software development and system administration to cybersecurity and artificial intelligence. With user submissions, comments, and voting, Lobsters provides a platform for collaborative learning and knowledge sharing among technology enthusiasts.

Lobsters

A year after the initial insights on game development in Rust, several major projects have abandoned Rust due to restrictive ownership and compile times. The Rend3 graphics stack was also abandoned and is now maintained as rend3-hp. Performance issues persist with the current graphics stack, which struggles to utilize more than 25% GPU load with an NVidia 3070. Maintaining 3D rendering in Rust requires significant effort, coping with rapid crate updates and a lack of spatial computation in rendering. Bevy offers an alternative but sacrifices Rust ownership for a dynamic ECS system.

Game dev in Rust, a year later

<blockquote>
At a more fundamental level, Rust rendering lacks the spatial component. Most of these renderers compute shadows by brute force - every light vs every object. This is O(N * M) and too slow as scenes get large.
</blockquote>
Most renderers do that in any language, because most renderers are either toy projects, or are meant for smaller games where this isn’t a problem.
<blockquote>
This is a consequence of where you cut apart the problem. Whether you can do an efficient renderer without becoming a whole game engine that has a full scene graph, like Bevy, is a big question. Either the renderer has to get its spacial info from the layer above, or it has to build its own spatial info. The renderer has to be able to calculate quickly which objects are in range of a light, for example.
</blockquote>
This is true for any 3D rendering project.
<blockquote>
The price Bevy pays for this is that it doesn’t really use Rust ownership. Bevy has its own run-time dynamic ECS system. You have to do everything Bevy’s way.
</blockquote>
“Unity has its own game object and component system, and modern Unity has its own ECS system. On a practical level, you can’t write a game in Unity without using one of those two paradigms.”
“Godot has its own node-based system. On a practical level, you can’t write a game in Godot without using its node-based system.”
“Unreal Engine has its own Actor-based system. On a practical level, you can’t write a game in Unreal without using its Actor-based system.”
Using an engine limits you to a paradigm. A Bevy game could be run though resources and a single system, but this is not practical. Bevy is not special here.
<blockquote>
It’s possible to do serious 3D in Rust, but it’s a real grind.
</blockquote>
It’s possible to do serious 3D in any systems language, but it’s a real grind.
There’s nothing stopping you from writing your Rust game code as a loop in main. Or from using singletons in Rust. Yes, it’s a little harder; but it is also safer. That’s the Rust trade-off: a little extra effort now, to save a lot of effort later. Among other things, bugs in Rust code are also, in general, easier to track down.