Comment by adrianN
9 months ago
> I'd argue as far as maintainability being the wrong value for indie games, as what we should strive for is iteration speed.
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 ended up with similar thoughts about automated testing in games too.
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.
I copied this exact same snippet and was going to comment the exact same thing.
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.
C++ is king for game engines, but many games opt for languages like Lua or Unreal Blueprints because C++ is to those as Rust is to C++
Personally I like Javascript
Right. Yes, you are correct. I assumed C++ was the language they replaced with Rust because they wanted to write lower level stuff, like their own engines (and they mention doing that).
It makes even less sense to use Rust to replace one of the higher level languages like C#.
Rust is not antithetical to iteration-based programming, it just makes you write a lot of heavy boilerplate to explicitly support that kind of style. The flip side of that is once the 'iteration'/'prototyping' phase is over, you can actually refactor the prototype into high-quality production code, instead of either throwing it away altogether and rewriting it from scratch (spoiler alert: this doesn't really happen most of the time, because it's viewed as pointless waste) or just putting it in production as-is (which is what people actually do, even though it's obviously a disaster in the longer run).
No, Rust is pretty antithetical to iteration-based programming. The language basically requires you to plan for the ownership model from the beginning, and it can be quite difficult to retrofit a changed ownership model into an existing program.
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.
If you're genuinely unsure about the ownership model (this is pretty rare in practice though) you can just use Rc<>/Arc<> (which allow for shared ownership via refcounting) and be no worse off than if you were coding in Swift.
Surely there's better choices if the primary desire is iteration speed, and a secondary or maybe even tertiary desire is maintainability/refactorability
Rust gets in the way a lot, as it's supposed to for safety. Maybe it'd be a lot faster to iterate on if some AI could auto fix your code to make the compiler happy.