- cross-posted to:
- [email protected]
- blogging
- gamedev
- cross-posted to:
- [email protected]
- blogging
- gamedev
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:
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 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.
Anti Commercial-AI license
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.
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.
Anti Commercial-AI license
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 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.
Well perhaps my experience in game dev and the OP’s are just wrong
deleted by creator
Hmm… Yeah both Rust and Go adherents seem unable to hear criticism which is unfortunate because they’re good languages with a lot of strengths
@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.
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
LMAO