That's not explaining ownership, that motivating it. Which is fine. The thing that's hard to explain and learn is how to read function signatures involving <'a, 'b>(...) -> &'a [&'b str] or whatever. And how to understand and fix the compiler errors in code calling such a function.

I think the most important lesson is this:

Ownership is easy, borrowing is easy, what makes the language super hard to learn is that functions must have signatures and uses that together prove that references don't outlive the object.

Also: it's better not store referenced object in a type unless it's really really needed as it makes the proof much much more complex.

That really doesn't explain the model because you have completely left out the distinction between exclusive/shared (or mutable/immutable) borrows. Rust made a large number of choices with respect to how it permits such borrows and those do not follow from this brief outline nor from intuition or common sense. For example, the no aliasing rule is motivated not by intuition or common sense but from a desire to optimize functions.

The most complicated aspect of the borrows comes about from the elision rules which will silently do the wrong thing and will work fantastically until they don't at which point the compiler error is pointing at a function complaining about a lifetime parameter of a parameter with the trait method implying that the parameter has to live too long but the real problem was a lifetime in the underlying struct or a previous broken lifetime bound. Those elision rules are again not-intuitive and don't fall out of your explanation axiomatically. They were decisions that were made to attempt to simplify the life of programmers.

And, after someone who doesn't know rust reads this neat and nice summary, they would still know nothing about rust. (Except "this language's compiler must have some black magic in it.")

Summarizing a set of concepts in a way that feels correct and complete to someone who understands them, is a much easier task than explaining them to someone who doesn't. If we put this in front of someone who's only worked with call-by-sharing languages, do you think they'll get it right away? I'm skeptical.

>the real owner has to be a reference-counted cell.

And what is that? Its easy to fall in the trap of making explanations that is very good (if you already understand).

This explanation doesn't expose anything meaningful to my mind, as it doesn't define ownership and borrowing, both words being apparently rooted in an analogy with financial asset management.

I'm not acquainted with Rust, so I don't really know, but I wonder if the wording plays a role in the difficulty of concept acquisition here. Analogies are often double edged tools.

Maybe sticking to a more straight memory related vocabulary as an alternative presentation perspective might help?

The second bullet in the second section is overpromising badly. In fact there are many, many, many ways to write verifiably correct code that leaves no dangling pointers yet won't compile with rustc.

Frankly most of the complexity you're complaining about stems from attempts to specify exactly what magic the borrow checker can prove correct and which incantations it can't.

I don't know how to read your comment other than "nothing hard is worth doing". Some things have benefits and drawbacks, is the existence of drawbacks always a non-starter for you?

I'm trying to phrase this as delicately as I can but I am really puzzled.

If someone wrote an article about how playing the harp is difficult, just stick with it... would you also say that playing the harp is a terrible hobby?

Rust design decisions are pretty hard to understand sometimes, Mojo is another language with a borrow-checker but it is not nearly as hard to learn as Rust due to making a few decisions. First is value semantics, in Rust people are told to always clone when learning, why isn't this semantics built into the language? It is what you have in most static languages - C, C++, Go, etc. This is the mental model many people come to Rust with.

Secondary, Mojo's lifetime does not tell the compiler when a value is safe to use but when it is safe to delete, in this way the lifetime is not scope based, references will extend the lifetime of the value they reference, but values will be destroyed immediately after their last use. In Mojo you'll never see "value does not live long enough".

Just these two design decisions defines away so many ergonomic issues.

The truth is that by the time you are a senior developer, you will have encountered the lessons that make rust worth learning but may not have truly understood all the implications.

Many people will think, I have a garbage collected language, rust has nothing to teach me. Even in garbage collected languages, people create immutable types because the possibility of shared references with mutability makes things incredibly chaotic that they look for immutability as a sort panacea. However, once you have immutable types you quickly realize that you also need ergonomic ways of modifying those objects, the methods you create to do so are often more cumbersome than what would be permitted for a mutable object. You wish there was some way to express, "There is a time where this object is mutable and then it becomes immutable." Enter the borrow checker.

Once you are borrow checking... why are you garbage collecting? Well, expressing those timelines of mutability and existence is a cost because you need to understand the timeline and most people would rather not spend that energy--maybe mutability or the poor ergonomics of immutable objects wasn't so bad. So, I garbage collect because I do not want to understand the lifetimes of my objects. Not understanding the lifetimes of objects is what makes shared mutability hard. Immutability eliminates that problem without requiring me to understand. Rust can teach this lesson to you so that you make an informed choice.

Of course, you can also just listen to me and learn the same lesson but there is value for many people to experience it.

Learning any programming language at all feels 10x as hard to beginners, so you might as well say programming is not worth learning period in this case. Anything new has a learning curve to it.

I think you can have a lot of debate on the design decisions on Rust, but I don't think the need for these articles tell you a lot about the language itself. I'd argue that Python needs articles like this more so than Rust does, but for entirely different reasons. In two decades of more and more programmers who aren't coming from an engineering background, I've yet to see anyone who used a Python generator or slots. Data Classes are less rare, but mainly in the form of pydantics "version". Which doesn't exactly matter for a lot of Python code... This is a world where 4chan can serve 4 million concurrent users an apache server running a 10k line PHP file neither of which have been updated since 2015... so you can be fine doing inefficient and entirely in-memory Python code 95% (or more) of the time.

That doesn't mean you should though. Imagine how much energy is being wasted globally on bad Python code... The difference is of course that anyone can write it, and not everyone can write Rust. I'm not personally a big fan of Rust, I'd chose Zig any day of the week... but then I'd also choose C over C++, and I frankly do when I optimise Python code that falls in those last 5%. From that perspective... of someone who really has to understand how Python works under the hood and when to do what, I'd argue that Rust is a much easier langauge to learn with a lot less "design smell". I suppose Python isn't the greatest example as even those of us who love it know that it's a horrible language. But I think it has quite clearly become the language of "everyone" and even more so in the age of LLM. Since our AI friends will not write optimised Python unless you specifically tell them to use things like generators and where to use them, and since you (not you personally) won't because you've never heard about a generator before, then our AI overlords won't actually help.

The article focuses on the learning curve rather than the problem Rust is solving, as an observation. Think you need both of those to draw a conclusion as to whether it’s worth doing.

I suspect an article like this says more about the author than the language.

Note I’m not being critical of the author here. I think it’s lovely to turn your passion into trying to help others learn.

> maybe that's a language design smell

why

> If a language needs an article like this, absolutely begging people to bite the bullet to learn it, maybe that's a language design smell.

The problem with articles like this is that they don't really get to the heart of the problem:

There are programs that Rust will simply not let you write.

Rust has good reasons for this. However, this is fundamentally different from practically every programming language that people have likely used before where you can write the most egregious glop and get it to compile and sometimes even kinda-sorta run. You, as a programmer, have to make peace with not being able to write certain types of programs, or Rust is not your huckleberry.

Maybe Rust is so complex, it is even more complex for an LLM to generate correct code (one-shot) without hallucinating non-existent functions.

Would rather have that than all the issues that JavaScript or any other weakly typed and dynamically typed language.

I have taken the time to learn rust and you're absolutely right. It's a very complex, design-by-committee language. It has brilliant tooling, and is still much less complex than it's design-by-committee competitor C++, but it will never be easy to learn.

"Rust is wonderful but humbling!"

It's an abstraction and convenience to avoid fiddling with registers and memory and that at the lowest level.

Everyone might enjoy their computation platform of their choice in their own way. No need to require one way nor another. You might feel all fired up about a particular high level language that you think abstracts and deploys in a way you think is right. Not everyone does.

You don't need a programming language to discover yourself. If you become fixated on a particular language or paradigm then there is a good chance you have lost sight of how to deal with what needs dealing with.

You are simply stroking your tools, instead of using them properly.

> Everyone should learn Rust.

I know this feels like a positive vibe post and I don’t want to yuck anyone’s yum, but speaking for myself when someone tells me “everyone should” do anything, alarm bells sound off in my mind, especially when it comes to programming languages.

Got recommended learning paths? I tend to prefer follow along adventures via video.

Python community famously learned the hard way that sometimes the programmer needs to know that there are multiple kinds of string.

Personally, I’ve been using to_owned instead. Some of the people looking at my code don’t write rust, and I figure it makes things a bit easier to understand.

I’m not sure why it’s counterintuitive that &str and String are different things. Do you also find it counterintuitive in C++ that std::string is different from const char* ? What about &[u8] and Vec<u8> ?

Just because a language is not high level enough to have a unique concept of "string" type doesn't mean you shouldn't take it seriously.

Strings are like time objects: most people and languages only ever deal with simplified versions of them that skip a lot of edge cases around how they work.

Unfortunately going from most languages to Rust forces you to speedrun this transition.

The question is worded weird for fun. One is a string slice (like char*) and one is String or &String, which is closer to an object.

C++ is a horribly cmplicated language, sometimes I have to cast something to an int when it's already an integer. /s

I have a hard time understanding why people have such a hard time accepting that you need to convert between different text representations when it's perfectly accepted for numbers.

You may be able to draw one that way but it completely neglects the way people use the term ordinarily “a steep learning curve” is not an easy to learn thing.

In point of fact, I think the intended chart of the idiom is effort (y axis) to reach a given degree of mastery (x axis)

It should be called "learning hill" instead.

People (colloquially) use phrases like "steep learning curve" because they imagine learning curve is something you climb up, a.k.a. a hill.

"Flattening the derivative of Rust's learning curve" really doesn't roll off the tongue though

This is incorrect. A learning curve measures expertise on the x axis and effort on the y axis. Hence the saying "steep learning curve".

What we want is an "effort/difficulty curve" that measures how difficult something typically is over time from introduction to proficiency

It also could mean you don't need to learn beyond a certain point.

Rust has better defaults for types than C++, largely because the C++ defaults came from C. Rust is more ergonomic in this regard. If you designed C++ today, it would likely adopt many of these defaults.

However, for high-performance systems software specifically, objects often have intrinsically ambiguous ownership and lifetimes that are only resolvable at runtime. Rust has a pretty rigid view of such things. In these cases C++ is much more ergonomic because objects with these properties are essentially outside the Rust model.

In my own mental model, Rust is what Java maybe should have been. It makes too many compromises for low-level systems code such that it has poor ergonomics for that use case.

I think the major decisions behind Rust is being explicit and making the programmer make decisions. No NULLs, no Implicit conversions, no dangling pointers. Lifetimes, Optional, Results, each Match branch needs to exist, etc.

Side note: Stack allocation is faster to execute as there's a higher probability of it being cached.

Here is a free book for a C++ to Rust explanation. https://vnduongthanhtung.gitbooks.io/migrate-from-c-to-rust/...

This might not be exactly what you're looking for, but I really like "References are like jumps": https://without.boats/blog/references-are-like-jumps/

Async and the "function color" "problem" fall away if your entire app is in an async runtime.

Almost 90% of the Rust I write these days is async. I avoid non-async / blocking libraries where possible.

I think this whole issue is overblown.

It doesn’t. The only language I know of in the same category as Rust is C++, which is much harder to learn and use.

I’ve found emulators to be a pretty poor first project for rust specifically for the reasons you alluded to: That you need to know to write it without heap allocation (or other hoop jumping so long as you avoid juggling lifetimes) when so much literature and example emulator code doesn’t do this is a recipe for a bad experience. Ask me how I know.

If you’re going to write an emulator in this style, why even use an imperative language when something like Haskell is designed for this sort of thing?

Compiler can figure that out, but the thing is compiler needs also to understand lifetimes at the site where this function is called. In general case compiler will not look into the code of a called function to see what it does, compiler relies on a function declaration.

That `longest` if defined without explicit lifetimes treated like a lifetime of a return value is the same as of the first argument. It is a rule "lifetime elision", which allows to not write lifetimes explicitly in most cases.

But `longest` can return a second reference also. With added lifetimes the header of the function says exactly that: the lifetime of a return value is a minimum of lifetimes of arguments. Not the lifetime of the first one.

You’re passing in two references and returning a reference.

The compiler knows the returned reference must be tied to one of the incoming references (since you cannot return a reference to something created within the function, and all inputs are references, the output must therefore be referencing the input). But the compiler can’t know which reference the result comes from unless you tell it.

Theoretically it could tell by introspecting the function body, but the compiler only works on signatures, so the annotation must be added to the function signature to let it determine the expected lifetime of the returned reference.

It's a design choice.

To make a compiler automatically handle all of the cases like that, you will need to do an extensive static analysis, which would make compiling take forever.

So long as you're aware that you're not optimizing, it's fine. Trying to build something useful as a new Rust dev while worrying about lifetimes is going to be quite challenging, unless your intention is to specifically learn about lifetimes and the borrow checker.

Yes the borrow checker is central to Rust, but there are other features to the language that people _also_ need to learn and explore to be productive. Some of these features may attract them to Rust (like pattern matching / traits / etc.)

>significantly faster for this kind of code

"Significantly" and "this kind" are load bearing sentences here. In applications where predictable latency is desired, cloning is better than GC.

This is also the baby steps of learning the language. As a programmer gets better they will recognize when they are making superflous clones. Refactoring performance-critical stuff in FFI, however, is painful and wont get easier with time.

Furthermore, in real applications, this only really applies to Strings and vectors. In most of my applications most `clones` are of reference types - which is only marginally more expensive than memory sharing under a GC.

> At that point you might as well be writing Java or Go or whatever though.

And miss Option/Result, enums, exhaustive pattern matching and the rest other dozens of features that I sorely miss when I drop to TS/Node.

I'm not using Rust for the borrow checker, but it's nice to have when I need it and not that much of an issue when I don't.

Except in no_std, I never felt any borrow checker pains.

I went through this the first year that I did Advent of Code in rust, like okay I read in all the strings from the input file and now they're in a vector, so I'm going to iterate the vector and add references to those strings into this other structure, but of course they're still owned by the original vector, that's awkward. Oh wait I can iter_into and then I get owned objects and that ownership can be transferred to the other structure instead, but now I need them to also be keys in a map, do I use references for that too?

Cloning small objects is lightning fast, turns out in a lot of these cases it makes sense to just do the clone, especially when it's a first pass. The nice thing is that at least rust makes you explicitly clone() so you're aware when it's happening, vs other languages where it's easy to lose track of what is and isn't costing you memory. So you can see that it's happening, you can reason about it, and once the bones of the algorithm are in place, you can say "okay, yes, this is what should ultimately own this data, and here's the path it's going to take to get there, and these other usages will be references or clones.

Not to mention that even though you can always refactor later, will you really? It’s much easier not to.

In my experience, hobbyist Rust projects end up using unwrap and panic all over the place, and it’s a giant mess that nobody will ever refactor.

For people who don't get the reference, this might be referring to the notoriously gnarly task of implementing a doubly-linked lists in Rust [1]

It is doable, just not as easy as in other languages because a production-grade linked-list is unsafe because Rust's ownership model fundamentally conflicts with the doubly-linked structure. Each node in a doubly-linked list needs to point to both its next and previous nodes, but Rust's ownership rules don't easily allow for multiple owners of the same data or circular references.

You can implement one in safe Rust using Rc<RefCell<Node>> (reference counting with interior mutability), but that adds runtime overhead and isn't as performant. Or you can use raw pointers with unsafe code, which is what most production implementations do, including the standard library's LinkedList.

https://rust-unofficial.github.io/too-many-lists/

So that you learn that loaning is for giving temporary shared^exclusive access within a statically-known scope, and not for storing data.

Trying to construct permanent data structures using non-owning references is a very common novice mistake in Rust. It's similar to how users coming from GC languages may expect pointers to local variables to stay valid forever, even after leaving the scope/function.

Just like in C you need to know when malloc is necessary, in Rust you need to know when self-contained/owning types are necessary.

I'd rather pair program with someone wary of double-linked lists, but is really hot on understanding ownership than the other way around.

Because most of my code is not doubly-linked lists!

Because you care about productivity and safety more than l33t h4x0r hazing rituals?

For me it was like Haskell. I spent an afternoon on it, my brain hurt too much, and I relegated it to the category of languages that are too complicated for what I need to do with a computer.

Languages I liked, I liked immediately. I didn’t need to climb a mountain first.

Unfortunately, yes. I still end up writing C++ instead of Rust for low-level system stuff. Since I also know Go - I usually prefer that when I need lean, middleware services. Learned Rust (somewhat) with great difficulty but still don't use it anywhere. Still haven't figured out how to design effectively using Rust and approaches suggested in that article like clone()/unwrap() stuff and refactor later just leave a bad taste in that mouth.

Coming from C++, I don’t find it hard to learn. I do find it annoying, don’t love the syntax and absolutely hate cargo.

To each his own, I guess….

The thing is, once you internalized the concepts (ownership, borrowing, lifetimes), it's very hard to remember what made it difficult in the first place. It's "curse of knowledge" in some sense.

What's changed since 2015 is that we ironed out some of the wrinkles in the language (non-lexical lifetimes, async) but the fundamental mental model shift required to think in terms of ownership is still a hurdle that trips up newcomers.

Yeah I struggled with it.