![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://programming.dev/pictrs/image/1f7e5534-88d3-4d6f-bc57-7cda9553890f.webp)
Do you have any sources about this “unfitness” of Rust for gamedev? From my experience many people have problems with the borrow checker due to habits they obtained coding in other languages.
I can’t say anything for sure, but I read this article, in conjunction with this article, before I made this post, so you might consider looking at it, and how it influenced me.
Edit: wait, I’ll extend this reply even more.
Edit 2: Done:
So I’d be interested what special behavior occurs in gamedev that makes coding in Rust more difficult than for other software.
Maybe it’s because the gaming industry is historically among the slowest industries, they stuck with DOS until there was literally no drivers on it for the latest GPUs, only then did they upgrade. There’s a video explaining how a recent AAA game could run on the steam deck, but not on Linux, it turns out the game was using a Windows XP library that’s too old for wine to support, so how did it work on the deck? they effectively added this to their code:
if platform_name == "steamdeck" { use_modern_library() }
, which explains why it only ran on the deck, but notice how they still stuck to the ~2003 library as the default even though the modern one works, that’s how much they hate change.
Considering the above, suggesting they change the particular way of their forefathers wouldn’t be fruitful, unless extremely obvious B I G gains are to be found. Notice how Jonathan Blow’s game development language is literally ‘C++
but better’, and how it mimics C++ in everything but the universally hated parts, and adds none but the universally wanted features. (as universal as an industry can agree on anything, that is)
That may be because games are a dangerous business, you pool all your resources in one project, and you get basically no income for up to four years, then you release and possibly succeed.
I also speculate that games aren’t really maintained, most of the best games I know only received 3 patches at most (version 1.3
). I think the priority isn’t: “How am I gonna remember how this works in 3 months from now and deal with technical dept”, it’s more like: “How can I implement this in a way that the only thing faster than the implementation time is the feature itself?”, so there is no fear of possibly breaking something that the checker can save you from down the road.
The last sentence kinda doesn’t make sense since the first 3 years are more that enough technical dept for Rust to start doing its thing, but IDK how they think.
Bonus: look for Jonathan Blow’s opinions on Rust on Youtube, he is an example of a studio owner fearing the risk of the possible “friction” that the Borrow checker could possibly cause.
Oh no don’t get me wrong, a year back I upgraded to an I5-7500 prebuilt, and it’s a beast for all my tasks. (maybe compiling is quick because I split modules a little too much?)
Your advice is good for not knowing what I’m making. If I was making something multi threaded with much state I would fear UB more.
Thanks, then I will remember to recreate bugs with
opt-level = 3
.Wait no, this doesn’t make sense if I don’t have access to the user’s machine, maybe I should send him a log-heavy version of some sort? How should I even what I am supposed to log? I should think about this some more before release.