Comment by qweqwe14
9 months ago
This is a decent article, but although the points themselves are valid, I think there's a core "issue" with (indie) gamedev itself.
The vibe that I'm getting is that it's filled with people that don't particularly care about programming, they just want to get stuff done(TM), this is also highlighted by the fact that they are willing to write completely inadequate code just to see things working. Rust is not that, and that's a good thing.
More generally, I'd say that in gamedev anything goes, as long as it's fun and isn't too buggy. Rust is not, and never will be able to accomodate that mindset, which again, is a good thing if you think for 2 seconds and consider what Rust is actually aimed at, which is safe systems programming.
You can have the core engine written in Rust and have a scriptable language on top of it, there aren't any major pain points in this regard. The scriptable language will be able to provide all of this hot-reloading-anything-goes-yes-sir bullshit that we all know and love.
tl;dr: Use the right tool for the job. A language designed for safe systems programming can't do non-safe non-systems programming very well. Who knew!
Virtually all of the points outlined in the article stem from the above.
It's a weird concept to "care about programming". Same as "inadequate code". I find this statement really condescending and completely confirms some of the cliché quotes that the author write in this article
By "care about programming" I basically mean writing maintainable code.
By "inadequate code" I mean code that does what the author wants at this point in time, but is completely unmaintainable and just bad. Sloppy practices, etc
Some people "care about shipping a product" others "care about programming".
That is why virtually no videogame is made with Rust.
2 replies →
Well sorry, but it wasn't obvious
I still think it's a bit condescending because at the end of the day, especially in indie games, there are less constraints of maintainability, you just want to ship something that works fast. On top of that, the performance constraints force you to do things perceived as heresy in other areas (global singletons, functions you can call from anywhere, not catching any exception...)
And finally, since when you're doing a game you're often trying to do something innovative and very specific, you can't really just pick a book about design and implement it.
So, I think it's not about "caring" or not, it's just that it's an useless overhead
It's said that software is never finished, only abandoned, but games actually do get finished. And at that point any maintainability is absolutely irrelevant. It's just very different to web programming.
Some software (other than games) can actually be fully finished, provided that it's scope is narrow enough.
It's really a question of differentiating between "finished" and "abandoned". Finished usually means that no new features are added, the only changes are bugfixes or minor improvements. Abandoned means no changes at all.
> And at that point any maintainability is absolutely irrelevant
This goes in line with my point though. The fact that Rust encourages writing maintainable code makes it unsuitable for gamedev, where speed of development and flexibility (even where it's bad) trumps everything else. That's why you need to have a scriptable layer on top of the core engine anyway.