Really well written, and well explained without any bait
Leaving Rust gamedev after 3 years
761–770 of 996 posts
Re: Leaving Rust gamedev after 3 years
#762Re: Leaving Rust gamedev after 3 years
#763As a game developer for about two decades, I've never considered Rust to be a good programming language choice. My priorities are reasonable performances and the fastest iteration time possible. Gameplay code should be flexible, we have tons and tons of edge cases _by design_ because this is the best way to create interesting games. Compilation time is very important, but also a flexible enough programming structure,…
> It is a different story for game engines, renderers, physics, audio, asset loaders etc. those are much closer to system programming but this is also not where we usually spend the most time, as a professional you're supposed to either use off-the-shelf engines or already made frameworks and libraries. But this is where industry interest (the little there is) lies for Rust, is it not? This is what the AAA studios th…
Visual scripting languages are easy to use and practical for low-complexity code, but they scale very poorly once the complexity increases.
Gameplay code is still better written with code, C# or C++ or sometimes Lua.
Re: Leaving Rust gamedev after 3 years
#764Earlier quoted context omitted.
I wish Microsoft had any direction on the 'way of the future' for native apps on Windows
If they did publish a “way of the future” direction, would you believe them? Fool me N times then shame on them, fool me N+1 times, then shame on me sort of thing.
The most infuriating thing is their habit of rebuilding things just about the time they reach a mature and highly stable state, creating an entirely new unstable and unreliable system. And then the time that system almost reaches a stable state - it's scrapped and it starts all over again.
WPF -> UWP -> WinUI -> WinUI 2 -> WinUI 3 is just such a ridiculous chain. WPF was awesome, highly extensible, and could have easily and modularly been extended indefinitely - while also maintaining its widespread (if unofficial) cross platform support and just general rock solid performance/stability. Instead it's the above pattern over and over and over.
And now it seems WinUI 3 is also dead, alas without even bothering with a replacement. Or maybe that's XAMARIN, wait I mean MAUI? Not entirely joking - I never bothered to follow that seemingly completely parallel system doing pretty much the same things. On the bright side this got me to finally migrate away from Microsoft UI solutions, which has made my life much more pleasant since!
Re: Leaving Rust gamedev after 3 years
#765Earlier quoted context omitted.
Rust is already in Windows: https://www.reddit.com/r/rust/comments/12yg3cp/microsoft_rew... Linux added Rust support: https://docs.kernel.org/rust/
Well aware, and it affects none of my points.
You asked:
> What systems are we talking about that benefits from Rust? Advanced weapon systems that should absolutely not fail? Controllers for air planes? Traffic controllers? Radar? Power grid?
You seem to be listing niche, specialised systems where a failure would be critical. But a simpler answer that is missing: mainstream operating systems — as I said, both Windows and Linux have been investing in Rust. Mainly as a way to increase memory safety.
Re: Leaving Rust gamedev after 3 years
#766Earlier quoted context omitted.
If you were to write the same code without using async you'd be trudging through a mess of callbacks and combinators. This is what writing futures code before 2018 was like. It was doable if you needed the perf but it sucked. Async is a huge improvement to readability and reasoning that we didn't have before.
No, actually that was just javascript. Programming environments with threading models don't have to live that way. Separate threads can communicate through channels and do quite well for themselves. See how it works is, you do something like let data = file.read(); and the it just sits there on that line until the read is done and then your data has the actual bytes in it and you just use them and go on with your lif…
> you do something like let data = file.read(); and the it just sits there on that line until the read is done and then your data has the actual bytes in it and you just use them and go on with your life.
That's exactly how async/await works, except that it translates to state machines under the hood which gives you great performance. No need to mess with threading models, at all.
Re: Leaving Rust gamedev after 3 years
#767As a game developer for about two decades, I've never considered Rust to be a good programming language choice. My priorities are reasonable performances and the fastest iteration time possible. Gameplay code should be flexible, we have tons and tons of edge cases _by design_ because this is the best way to create interesting games. Compilation time is very important, but also a flexible enough programming structure,…
> a flexible enough programming structure, moving things around and changing your mind about the most desirable approach several times a day is common during heavy development phases. That's the kind of code for which Rust-like languages shine. Rich type systems make it easy to change your mind about things and make large changes to your code with confidence. (Whether Rust tooling is actually at a level to take advan…
Pretty much every compiled language with a static typesystem has that "large-scale refactoring support" though. That's not Rust's USP, on the contrary: a too strongly typed language can make refactoring actually harder than it needs be. The sweet spot is somewhere in the middle (where exactly is up for discussion of course).
Re: Leaving Rust gamedev after 3 years
#768Earlier quoted context omitted.
> I'd expected some AAA title to be written in Rust by now. I'm disinclined to believe that any AAA game will be written in Rust (one is free to insert "because Rust's gamedev ecosystem is immature" or "because AAA game development is increasingly conservative and risk-averse" at their discretion), yet I'm curious what led you to believe this. C++ became available in 1985, and didn't become popular for gamedev until…
I really hope that C++ evolves with gamedev and they become more and more symbiotic. Maybe adoption of rust by gamedev community isn't the best thing to wish to happen to language. Maybe it is better to let other crowd to steer evolution of rust, letting system programming and gamedev drift apart
I think I don't know a single gamdev who's fond of "modern C++" or even the C++ stdlib in general (and stdlib changes is what most of "modern C++" is about). the last good version was basically C++11. In general the C++ committee seems to be largely disconnected from reality (especially now that Google seems to be doing its own C++ successor, but even before, Google's requirements are entirely different from gamedev requirements).
Re: Leaving Rust gamedev after 3 years
#769Earlier quoted context omitted.
>now you're having to fire up a tokio runtime I've been developing in (mostly async) Rust professionally for a about a year -- I haven't written much sync rust other than my learning projects and a raytracer I'm working on, but what are the kind of common dependencies that pose this problem? Like wanting to use reqwest or things like that?
> Like wanting to use reqwest or things like that? Yes. Reqwest cranks up Tokio. The amount of stuff it does for a single web request is rather large. It cranks up a thread pool, does the request, and if there's nothing else going on, shuts down the thread pool after a while. That whole reqwest/hyper/tokio stack is intended to "scale", and it's massive overkill for something that's not making large numbers of request…
You don't have to do that, Tokio also provides a single-threaded runtime that just runs async tasks on the main thread.
Re: Leaving Rust gamedev after 3 years
#770Earlier quoted context omitted.
Exactly, it's all about the ecosystem and very little about the language features
C++ classes with inheritance are a pretty good match for objects in a 3D (or 2D) world, which is why C++ became popular with 3D game programmers.
Hmm no not really in my experience. Even the old "Entities and Components" system in Unity was better, because it allowed to compose GameObject behaviour by attaching Component objects, and this system was often replicated in C++ code bases until it "evolved" into ECS.