Leaving Rust gamedev after 3 years
Leaving Rust gamedev after 3 years
This was a really good summary of what Rust feels like in my opinion. I'm still a beginner myself but I recognize what this article is saying very much.
The hacker news comments are as usual very good too:
You're viewing a single thread.
That being said, there is an overwhelming force in the Rust community that when anyone mentions they're having problems with Rust the language on a fundamental level, the answer is "you just don't get it yet, I promise once you get good enough things will make sense". This is not just with Rust, if you try using ECS you're told the same thing. If you try to use Bevy you'll be told the same thing. If you try to make GUIs with whichever framework you choose (be it one of the reactive solutions or immediate mode), you'll be told the same thing. The problem you're having is only a problem because you haven't tried hard enough.
Ugh, I hate this attitude in the Rust community. It's the elitist neckbeard attitude the early linux forums were known for that's still present in places like the Arch community.
The best advice I read about these places is to avoid them and just do stuff that works. Writing Haskell and don't want to worry about whatever highbrow computer science gatekeeping concepts? Use the beautiful escape hatch to imperative programming: monads.
do { blablabla }. Is the Rust borrow checker complaining about ownership? A quick.clone()to a new variable will probably shut it up and allow you to move on. "Ermagerd, scripts should be in bash and only readable to you!", a quick ruby or python script should solve that for you. "systemd is -", just stop reading there and keep using systemd. It does the job.This is where experienced people will often say that this becomes less of an issue once you get better at the language. My take is, while that is 100% true, there's a fundamental problem of games being complex state machines where requirements change all the time.
This is probably the best argument in the article. Rust is probably great for systems that don't have a lot of changing requirements, but fast iteration and big changes probably aren't its strong suit. I've found that planning a project ahead of time has reduced the amount of refactoring needed regardless of language, but that's because I was solving a static problem and thinking of a little bit of flexibility towards other features. Games probably aren't like that.
No language fits every usecase and it's completely find for it not to fit this dude's flow of writing games nor the types of games he's writing. It's a good thing he came to the conclusion sooner than later.
Rust is probably great for systems that don't have a lot of changing requirements, but fast iteration and big changes probably aren't its strong suit.
I agreed up until this. Fearless refactoring is a huge benefit of Rust. If the type system of another language allows the refactoring more easily without as many compilation failures, it will probably surface more runtime bugs.
Fearless refactoring is a huge benefit of Rust.
That's not the issue. The issue is the borrow checker making things slower to write. Changing requirements isn't just moving code back and forth, it's changing the existing code, moving it around, adding new dependencies, using existing code in a new way, and so on. Not easy to do if the borrow checker is screaming at you about some moved ownership.
That's what dynamically typed languages are good at: pass in a dict/object/hashmap/whatever with some attributes to test something out, pass that around, transform it, add keys/fields, extract parts of it, transform them and return those, etc., see that it's working, and then you refactor it with proper typing, linting, and tests where a borrow checker is very very welcome.The borrow checker is useful for a lot more than memory safety. This is something I have been repeating for years, but unfortunately people new to the language don't understand it yet.
E.g. Rust is the only mainstream language where it isn't possible to read from a file handle after it's been closed. There are numerous other common benefits of it that apply to general purpose programming, like not being able to mutate a collection while you're iterating over it.
It's a very common practice in Rust to enforce domain invariants using Rust's ownership rules, and those things cannot be enforced at compile time in other languages that don't have ownership.
The borrow checker is also usually pretty easy to get around with just a bit of experience in Rust.
It's not like Rust is the first language which requires you to reason about ownership. People still write tons and tons of C++. Rust is much faster to write than C++ in my experience, because ownership is checked by the compiler instead of requiring the human programmer to constantly think and reason about.
I wouldn't write gameplay code in Rust like I posted above, but most of the complaints about the borrow checker making Rust somehow exceptionally hard to write are overblown imo. There's a learning curve but then it makes sense.
Antagonizing the borrow checker is wrong. If it screams it does so to prevent you from writing a mistake. Eventually once you have enough experience you should write code in such a way that doesn't trip the borrow checker because you know how to properly handle your references.
Is it difficult to learn at first? Yes, but the benefits of learning this outweighs the downsides such as writing code that may use references when it shouldn't.
I'm not a Rust aficionado, but the few Rust I've written opened my eyes on issues that I have been dealing with in other languages but for which I was blind.
Lastly I tried following a Godot project tutorial that was using GDScript except I challenged myself to follow it but rewrite the examples given using Rust's bindings for Godot. It was definitely more cumbersome to work with, but I might also have been doing something wrong (such as blindly transcribing GDscript instead of writing more idiomatic Rust).
All of that to say 1) borrow checker is your friend and 2) scripting languages will always be more convenient at the cost of being way more dirty (way less safeties)
In the end you need to pick the right tool for the job. Multiple tools may be used within the same project.
I greatly fear refactoring in Rust. Making a single conceptual change can require a huge number of code changes in practice, especially if it's a change to ownership.
Refactoring in languages like Java and C# is effortless in comparison, and not error prone at all in a modern codebase.
You can use RC and clone everywhere, but now your code is unreadable, slow, and might even have memory leaks.
You can use slotmaps everywhere, but now you're embedding a different memory model with verbose syntax that doesn't even have first-class references.
I don't even dislike Rust; I recently chose it for another project. I just think it has clear weaknesses and this is one of them.
I greatly fear refactoring in Rust. Making a single conceptual change can require a huge number of code changes in practice, especially if it’s a change to ownership.
I think this is a fair criticism, but I think you and the poster you responded to are talking about different things. Usually when people use the term “fearless” in relation to Rust, it means the language provides a high level of confidence that what you’re delivering is free of mistakes. This certainly applies to refactoring too, where usually after you are done, and things compile again, you can be reasonably confident things work as before (assuming you didn’t make other changes the type system can’t catch for you).
The kind of fear you are describing sounds more like a discouragement because of the amount of work ahead of you. That’s fair, because Rust does sometimes make things harder. I just think many Rust developers will disagree with you, not because you’re wrong, but because they may not feel the same type of discouragement, possibly because they’ve learned to appreciate the rewards more.
I think you're wrong. But this is clearly an article of faith amongst rust developers
What I said isn't even what I'd consider subjective. There is a very clear, logical, scientific reason for that. Not sure what you think I'm wrong about.
Can you give an example of why you think Rust just makes it needlessly hard to refactor?
I've worked in game dev so I get the point about iteration. It's not about doing proper reactors - it's about quick hacks to try something out. When your hack is good, then you do it properly - or maybe not at all if the hack works.
The respondents here are acting like code must be at all times provably correct and and Rust is great because it helps with that. That is indeed very cool but it's SLOW when you need quick iteration. It's not that you need to quickly iterate the code per so, it's usually the game experience you're iterating and that doesn't actually NEED code to be perfect or even good.
Ive used Rust professionally for six years now and have done many quick hacks. It is really easy to do. Basically just don't use references / clone everything to avoid lifetime and ownership issues, and use unwrap everywhere to avoid proper error handling. It's really that easy almost all the time.
The nice thing about that is once you're done with the prototype, just remove the unwraps and you can optimize stuff by removing the clones.
@kaffiene @asdfasdfasdf It
s slow when you dont know what youŕe doing. For example, build a linked list in #rustlang is different then build one in java, because you can´t leave the variables in a wrong state. It's only a different approach, not a slow approach.OK. I'm dumb. There are dozens of languages where I appear to not be dumb using so I'll stick to them I guess
That's a sad attitude to have. Rust is really great, but it does have a learning curve. If you do want to give it a shot, just reach out online and there are many people who can help with suggestions.
@asdfasdfasdf @kaffiene As the friend above says, rust require some time and have a learning curve. Its very different, and thats why people gets strugling with the language. As you got proficience, it will save you hours of debug. I suffered with the learning curve also, but I needed to change the way I was think about how to program.
@asdfasdfasdf @kaffiene I think build a linked list is the last stage of learning rust, because linked lists has circular references that can lead to memory leaks and other memory issues. Build one with rust is hard, because the compiler will not easy for you to make mistakes, but if you can write a linked list, you can write anything in rust. Try this book.
Yeah it's sad that I just want to get stuff done and use the tools that are actually good at that. Point me to great Rust gamedev tools that are actually getting used to ship great games and I'll give them a go. I think criticising people who raise valid issues about Rust in a context where it has no cut through and no depth says more about you, frankly. Programming languages aren't all good at everything and that's not a personal slight on you or the Rust communiry
@kaffiene @asdfasdfasdf i think part of the issue is that one group of devs is saying "rust is great for gamedev" by which they mean its a great language to develop games which are closer to game engines themselves in, or even custom engines. Then another group says "no it sucks" but they are talking about the scripting approach, where you don't care what happens under the hood
Rust fits the first group well, and the second not at all, and the issue is that both dont see the difference between
@kaffiene @asdfasdfasdf by which i mean:
if you want to develop on the level of a engine, even if you're not makign a entire engine, Rust is IMO the most productive language. But these things also take a lot of time, which is why you don't see big games being finished. There are some like Tiny Glade where the devs built a entire custom renderer on the other hand.
Yeah, at this point I'm talking about Rust's fit as a general purpose language and being good at refactoring. I think Rust is great for both of those and that it isn't very subjective.
But regarding Rust for game dev, I have no idea. I have never done game dev, so it's definitely possible it isn't good for it for some reason.
I'm also saying scripting languages will break very easily when you refactor things. I didn't think that was that controversial...
It’s the elitist neckbeard attitude the early linux forums were known for that’s still present in places like the Arch community.
LMAO