Rust makes you care about a lot of things that a general purpose application language shouldn’t make you care about! In that sense it’s not a good application language (though in other senses, it’s still better than most competitors, sadly).
Comments
Log in with your Bluesky account to leave a comment
Yes, I think that's probably fair. In my totally subjective experience, those things have been less of a problem than things other languages do *worse*, but I completely agree that's going to be very much down to personal taste.
For a brief picosecond, I considered that an opportunity, but then I realised that changing that would be the most thankless and maddening task in the history of modern civilisation.
Or at least, my experience has been that the up front trade offs Rust forces upon you (caring about things) are worth it when you don’t have to learn advance techniques to reach pretty commonly required performance levels.
Being an imperative language (more familiar to most users) with sum types and decent guarantees about aliased mutable state. It brings the lessons from pure functional programming to imperative programming.
As someone who writes Rust and other ML derivatives for fun but a lot of Go (among other things) for my paycheck, I was so overjoyed when I saw Borgo and so incredibly sad when I realized it looked like it never went anywhere.
I used to agree with this re. games, but I realized over the past couple of years that the ubiquity of multicore complicates this a lot. I don't see a way to multithread game logic in a scalable way without aliasable-xor-mutable, and Rust is kind of the only game in town for that right now.
I agree with you re games! I think there are many applications where the performance difference doesn’t justify the additional thought about data structuring that Rust requires because it gives users so much control
for the most part many things i use rust for are simply because getting a native binary out is the least annoying distribution mechanism for me. and the tooling is good! this is very funny to me though, since i also use rust (and learned it!) for more typical "need to care" reasons
Yeah I mean I use it for things that can't be done in other environments, so it makes sense to carry over my expertise to solve problems that can be done in other environments
I mean, I've tried to come up with potential solutions, and I really can't, other than "test orderings and fix races manually" (what you do in Unity DOTS), which isn't a very attractive option when there's an alternative that lets you just not have to worry about it.
I wouldn't be surprised if there's some hypothetical language that's better at solving the problems of scalable multithreaded game dev than Rust, because as you correctly point out manual memory management is a burden, but sadly there doesn't seem to be any work in this area. Zig and Jai aren't it.
How do you feel about Swift for game development? With the new data-race safety guarantees, combined with automatic reference counting, it sounds like it could be a good match
I think the combo of a custom job scheduler with safety checks & "high performance c#" compiler that we pursued independent of DOTS is still a great programming model for games. I still think this even having left Unity & doing rust for a while now
Comments
https://github.com/sponsors/lpil