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.

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.

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?