That seems to be the crucial point. Rust is optimized for writing complex systems software in large teams. That’s not a great fit for a small team hacking on something that is at least in part an art project. You wouldn’t choose something like Ada for that either.
I've run into this in a side project I'm working on, where my indecision over which ownership models are actually workable in the API to satisfy the needs I have means almost all of the coding is spent just proving I can get an ownership model working over having a skeleton code that can do something. And still, even as lacking as functionality as this codebase is, swapping to a new ownership model takes several minutes of coding. Trying to do this kind of exploration on a codebase that has real functionality would mean spending hours of change just to move some property from here to there.
Why choose Rust if you don’t care about maintainability and long term stability? Those are core values of the language!
The language choice was wrong from the start. C++ is king for games so if you care more about delivering features and fast prototyping why not go with that?
Maybe Rust is not a good language for rapid iteration in the game industry. And that’s ok I think.
Personally I like Javascript
I really enjoy having automated tests and automated tests solve problems. Like, I absolutely love our molecule test suite for our infrastructure code and it gives us huge value. The smoke tests we have for the infrastructure running after deployments are amazing. It's liberating in an environment of rapid and chaotic changes everywhere, complex interdependencies, as well as pressure on top.
However, if I try to transfer that kinda approach to a game it just... fails?
But the realization is: In games, many behaviors and systems are actually far simpler and less intertwined in arcane ways, and code changes actually less frequently and dramatically than at work.
I could see structured testing in e.g. turn based strategy games and such, so you can test that the culture per turn is correctly calculated based off of many different situations and such.
But in many smaller projects I've had, you write some janky code, make sure the enemy behaves as expected... and never touch or change that piece of code ever again. And it just doesn't break, because no fundamental part below it ever changes, because then the entire house of card would fall apart.
It feels dang weird, but it works very well for smaller projects.