Stop making me memorize the borrow checker

A theme I’m noticing more frequently as Rust gains popularity is people trying to use Rust even though it doesn’t fit their preferred way of coding.

There is a learning curve for everyone when they pick up a new language: You have to learn how to structure your code in ways that work with the language, not in the ways you learned from previous languages. Some transitions are easier than others.

There should come a point where the new language clicks and you don’t feel like you’re always running into unexpected issues (like the author of this article is). I might have empathized more with this article in my first months with Rust, but it didn’t resonate much with me now. If you’re still relying on writing code and waiting for the borrow checker to identify problems every time, you’re not yet at the point where everything clicks.

The tougher conversation is that for some people, some languages may never fully agree with their preferred style of writing code. Rust is especially unforgiving for people who have a style that relies on writing something and seeing if it complies, rather than integrating a mental model of the language so you can work with it instead of against it.

In this case, if someone reaches a point where they’re so frustrated that they have to remember the basic rules of the language, why even force yourself to use that language? There are numerous other languages that have lower mental overhead, garbage collection, relaxed type rules, and so on in ways that match different personalities better. Forcing yourself to use a language you hate isn’t a good way to be productive.

> A theme I’m noticing more frequently as Rust gains popularity is people trying to use Rust even though it doesn’t fit their preferred way of coding.

I could've expressed the sentiment in this blog post back when I started playing with Rust ~2016. Instead, I ended up learning why I couldn't pass a mutable reference to a hashmap to a function I'd looked up via that hashmap (iterator invalidation lesson incoming!).

The kind of bug I was trying to add exists in many languages. We can only speak in general terms about the code the blog post is talking about, since we don't have it, but couching it in terms of "doesn’t fit their preferred way of coding" misses that the "preferred way of coding" for many people (me included) involved bugs I didn't even realise could exist.

> The kind of bug I was trying to add exists in many languages

Any example except C++? BTW, the closest thing possible in C# is modifying a collection from inside foreach loop which iterates over the collection. However, standard library collections throw “the collection was modified” exception when trying to continue enumerating after the change, i.e. easy to discover and fix.

I'm pretty sure most languages just make the reasonable assumption that you want to map to the object so it uses the pointer for hashing and not actually hash its value.

> you’re not yet at the point where everything clicks

This just seems to be the standard excuse I read any time someone has a critique of Rust.

> modifying a collection from inside foreach loop

This is exactly what the mutable map pointer was for, for the function to be able to modify the collection; C++ would result in potentially iterating garbage, C# it sounds like would throw an exception (and so show the design wouldn't work when I tried to test it), Python definitely didn't do a graceful thing when I tried it just now. And if I had a collection struct in C, I'm sure I could've done some horrible things with it when trying.

The best of those outcomes is C#, which would've shown me my design was bad when I ran it; that could be as early as the code was written if tests are written at every step. But it could be quite a bit later, after several other interacting parts get written, and you rely on what turns out to be an invalid assumption. For Rust, the compiler alerted me to the problem the moment I added the code.

FTR I ended up accumulating changes to the map during the loop, and only applying them after the loop had finished.

EDIT: Python did do something sensible: I didn't expect pop'ing an element from the list to echo the element popped in the REPL, and got a printed interleaved from front to back, which does makes sense.

> Any example except C++?

Java for sure.

> However, standard library collections throw “the collection was modified”

Java is similar, but the exception is done on a "best effort" basis, and is not guaranteed.

Python will raise a runtime exception if you modify the dict you are iterating over. You can work around that by copying a snapshot of the whole thing or just the keys and iterating over that.

C++ will laugh in invalidated iterators.

Of course you can erase from the container you are iterating over, but you have to make sure to continue the iteration using the iterator returned from the erase function and avoid storing copies of .end()

Python defined the semantics of modifying lists while iterating over them, which is better than c/c++ just calling it undefined behavior, but I've basically never seen it not be a bug. Either I end up creating a copy of the list to iterate over, or figure out a way to defer the modifications, or write a new list. Imo the c# /Java behavior of detecting and throwing is probably the best option for non borrow checked languages.

And yet, such mutation is perfectly safe as long as you only change the value of existing keys. But you can't do that in Rust.

You would use interior mutability, putting things in Cells in the map.

What did the Rust community expect to happen if they so strongly and often claimed that Rust is easy to learn and user-friendly?

And how did we get from that to “for some people, some languages may never fully agree with their preferred style of writing code”?

If a C++ programmer (ideal Rust learner) says four years in that the ergonomics of Rust are bad, then based on my own experience I will believe them.

I don’t write something to see if it compiles either, I design every single line of code. But with Rust (and a lesser extent C++) a lot of that design is for memory safety and not necessary for the algorithms.

Rust is easy to learn and user friendly. But if you are stuck in your ways and insist on writing code exactly like you did in another language you will have a hard time. This is true for every language on earth. Rust will refuse to compile, whereas other languages give you much more freedom to not use them as they are meant to.

> If a C++ programmer (ideal Rust learner)

There is no ideal learner.

> This just seems to be the standard excuse I read any time someone has a critique of Rust.

The guys who parrot this blend of comments don't seem to be aware that cognitive load is a major problem, not a badge of honor.

> Rust is easy to learn and user friendly. But if you are stuck in your ways (...)

It's high time that people in the Rust community such as you just stop with this act.

The Rust community itself already answered that they find "Rust too difficult to learn or learning will take too much time" as a concern to not use Rust. The community also flagged Rust being too difficult as one of the main reasons they stopped using Rust.

https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Surve...

Anyone who has managed to become proficient in C++ is smart enough to be proficient in Rust. The only too difficult part is adapting to the rust way of doing things and some refuse to.

There is a saying among Haskellers that "Haskell has the steepest unlearning curve". Sounds like Rust is similar.

Rust is not easy to learn. Stop saying that. It is hard. It is harder than C#, harder than Python, harder than Java, harder than PHP, harder than JS, Harder than TS.

Saying it is easy to learn is just delusional and does a disservice to the language. Rust has many advantages, but trying to get people learning the language by lying about why they should learn it is just dumb.

> What did the Rust community expect to happen if they so strongly and often claimed that Rust is easy to learn and user-friendly?

No one really claimed it was easy to learn. Find me one Rustacean that claims Rust is as easy as Python/Ruby/Go.

But it is higher level language with decent ergonomic and in such way it can be interpreted as user-friendly.

> If a C++ programmer (ideal Rust learner)

If Java programmer (me) can learn Rust in a year enough to contribute to Servo development, you (ideal Rust learner) should have no problem either.

Plus Google saw about 6-month to get people up to speed with Rust.

Everybody who has managed to become proficient building a school is smart enough to be proficient in building a library.

So building libraries must be easy, that's totally why you can become an architect over night ... What a stupid argument you delivered

You just seem to have missed the point the author was making. I will try to clarify it: when you find out that a decision you made early on didn't pan out and you're forced to change the lifetime of some data, this will incur major refactoring in Rust and that will cause you to lose a lot of time. It's nearly impossible to avoid mistakes like this, not because you don't know Rust enough, that's almost completely irrelevant... it's because you just can't predict the direction your design will go to after many iterations and changes in requirements, which are unavoidable in the real world.

Replying to that with "Rust is easy to learn" just makes it sound like you didn't even understand what you're trying to reply to.

> Anyone who has managed to become proficient in C++ is smart enough to be proficient in Rust.

I'm not sure you're paying attention. The people who are saying Rust is too hard are the Rust community itself. They said so in Rusty's annual survey. The ones who participate in it are Rust users who feel strongly about the topic to participate in their governance.

It's Rust users who say Rust is too hard. There is no way around this fact.

> C++ programmer (ideal Rust learner)

Well there's your problem. Rust does look like a semi-colon language, that's intentional, but if that's all you understand you're probably going to struggle.

The "ideal Rust learner" would have an ML, such as Ocaml or F#, maybe some Lisp or a Scheme something like that, as well as a semi-colon language like C or Java not just the weird forced perspective from C++

One experiment I probably won't get to try is to teach Rust as First Language for computer science students. Some top universities (including Oxbridge) teach an ML as first language, but neither teaches Rust because of course Rust is (relatively) new. The idea is, if you teach Rust as first language your students don't have to un-learn things from other languages. You can teach the move assignment semantic not as a weird special case but as it it really is in Rust - the obvious default assignment semantic. I pass a Goose to a function, obviously the Goose is gone, I gave it to the function. Nobody is surprised that when they pass a joint they don't have the joint any more, so why are we surprised when we pass a String to a function and the String is gone now? And once we've seen this, the motivation for borrows (reference types) is obvious, often we don't want to give you the string, we just want to tell you about a string that's still ours. And so on.

> Well there's your problem. Rust does look like a semi-colon language, that's intentional, but if that's all you understand you're probably going to struggle.

This is a silly point to make. What makes a C++ programmer a C++ programmer is not an uncanny ability to find a semicolon on the keyboard. It's stuff like using low-level constructs, having a working mental model of how to manage resources at a low level down and how to pass and track ownership of resources across boundaries. This is not a syntax issue.

It's absurd. You have people claiming that Rust is the natural progression for C++ programmers because their skillsets, mental models, and application domain overlap, but here are you negating all that and try to portray it as a semicolon issue?

> No one really claimed it was easy to learn.

It's a great example of unintended comedy the fact that the comment right below yours is literally "Rust is easy to learn and user friendly."

https://news.ycombinator.com/item?id=42162676

Learning the language fundamentals is not "cognitive load" more so for rust than c.

With c you also need to understand pointers, manual allocation, volatility, is that bad?

Oh! Alas the apparent syntax similarity is misleading. If you prefer imagine I wrote "C-like language" anywhere that I wrote "semi-colon language". It's not really about the semi-colon, indeed the semi-colon isn't even doing the same thing and that's a clue†. You see, the typical semi-colon languages you'll have used such as C++ or Java have these "everything is a machine integer" type systems which were a small step up from the "Who needs a type system" of their predecessors but aren't anywhere close to what you'd expect in an ML or a functional language.

So this means there's a substantial learning curve, or, if you try to just keep writing C++ even though you're in Rust, an impedance mismatch. It looks superficially like the thing you're used to, but that's not what it is.

† In Rust the semi-colon is turning your expression into a statement, but in the semi-colon languages it's a separator, everything is a statement anyway. So while a rust program might say let x = if k > 3 { plenty(k) } else { too_few() }; in the semi-colon languages there's a whole separate ternary operator provided to do this trick - in fact they don't have any other ternary operators and so they often call this "the" ternary operator which is very funny if you come from a language which has the multiply-accumulate operator...

Sure but that's a no one. Same as me. Find someone on Rust team saying that. Or someone teaching Rust constantly.

I can see user friendly. It's got a solid ecosystem around it, and compiler is super helpful with errors.

But easy to learn it ain't.

That's an... uncharitable interpretation of the phrase "semi-colon language".

The comment made sense to me: it's not at all about semicolons, but the semicolon isn't a bad marker to distinguish between language families. It's closely related to expression- vs statement-focused languages, which if you squint is similar to the distinction between imperative and functional languages. Though the latter distinction is less relevant here, I'm just using it to point out that semicolon syntax is suggestive of semantics, even if it is itself just a superficial bit of syntax.

You are correctly describing the awareness of resource management as an important characteristic, but that resource management is heavily intertwined with how values flow through the language syntax, which brings us back to expressions vs statements.

> Anyone who has managed to become proficient in C++ is smart enough to be proficient in Rust.

I agree completely. But I'd reword your statement slightly as "Anyone who has managed to become proficient in the language that is notorious for being one of the most complicated and convoluted languages in existence, with the most footguns per line of code and a CVE record that proves its difficulty, ..."

It changes the conclusion just a tad.