Hi, document author here. I learned Rust because I was too scared to learn C++, lol.

Rust has a steeper learning curve than most languages but it also has a very beginner-friendly and welcoming community. So don't be scared, you can do it! If you get stuck on something it's always easy to get help.

As someone who doesn't know Rust yet I feel there's a "do this instead" missing to point 8. It's not clear to me how to do it instead.

In my (admittedly somewhat limited) experience, these don't come up that frequently. except number 5; I've had several times where I've had to be aware of where references are coming from.

I would say give Rust a go anyway. Worst case is you end up not getting along with it, best case is you now have a new tool to reach for.

For most of these, the net result is that the compiler behaves strangely, but the programs that compile still work as intended. These are intermediate to advanced Rust concepts, and most programmers can eventually learn them from experience fighting with the compiler.

If fighting with the compiler is necessary for learning, I think that would men lots of users would drop out, not “eventually learn”.

That’s why lots of work has been done and still is being done to make that “work with the compiler’s help”.

The thing is: in _any_ programming language, whenever you pass anything mutable to another function, you have to think about ownership.

For the sake of reliability, rust makes that explicit, where other languages such as C and Java assume the programmers know what they are doing. To not make that too tedious for the programmer, rust also infers quite a few rules.

Rust is getting better on both fronts. Its ability to infer ownership grows, and it gets better at reporting problems it can’t solve on its own.

> If fighting with the compiler is necessary for learning

I don't think "fighting the compiler" is a useful concept. No matter what language you're learning, you have to learn both the language's syntax and semantics.

If your program barfs up an error at runtime because you made a semantic error the language forbids, that's no better than barfing up an error at compile time because you made semantic error the language forbids.

So it's both more accurate and more precise to say that a language's semantics might be complicated or subtle, but the compilation step is orthogonal to the actual problem you're talking about.

The difference in when the error is flagged is a large difference, though. Usually, runtime semantic errors won’t be flagged until the program tries to actually perform some nonconforming action. That lets the programmer work on unrelated issues by simply not exercising the defective path.

Compile-time errors, on the other hand, ensure that the entire program meets some baseline of correctness before any of it is run. Neither is necessarily better or worse than the other, but they are categorically different things that have their own effects on the experience of writing programs.

You’re right, of course. To my mind, one way to classify how severe mistakes are is by looking at their potential consequences. For programming, there’s unpredictable, hard-to-identify bugs with far-reaching effects at oneend of the scale. On the other end are mistakes that announce themselves loudly, in a predictable way that are isolated from everything else.

My original comment was a clumsy attempt to reassure ‘antpls and other Rust beginners that lifetime errors generally manifest as the less-troublesome kind on this scale.

Pretty much all misconceptions named there can be avoided by following the advice that every Rust programmer will give you: read the damn book, it will save you a lot of time.

If you are in the category of users that never RTFM, then I guess this article might be for you, but then kind of by definition, you won't read this article either, so...

---

For example, in C++ a generic `T` can only mean an owned type:

    template<class T> void foo(T t);
    template<class T> void bar(T& t);

You can't pass `foo` a reference to `T`, you'd need to pass it an owned type like `foo(std::ref(t))` instead or similar.

In Rust, when you write

    fn foo<T>(t: T);

you can call `foo` with an owned type or a reference, no problems, generic types are... well... generic.

So if you start writing Rust code with a C++ background without reading the book, then you might probably think that generics in Rust work like templates in C++. One couldn't be more wrong about this, they are in fact completely different language features. They might solve very similar problems, but they are as different as Python is from Haskell.

> For example, in C++ a generic `T` can only mean an owned type:

Wrong.

  template<class T>
  void foo(T t) {
  }

  int main() {
    int x = 0;
    foo<int&>(x);
  }

Unadorned Ts as function parameters will by default be deducted as value types, but a generic T parameter can represent references just fine. This is especially important for template classes.

> you might probably think that generics in Rust work like templates in C++. One couldn't be more wrong about this, they are in fact completely different language features. They might solve very similar problems, but they are as different as Python is from Haskell.

it seems to me that they are more similar than different.

> Wrong.

Indeed, thanks for the correction!

> it seems to me that they are more similar than different.

I think the Haskell vs Python comparison is accurate. Rust generics are strongly typed (definitions are checked), while C++ templates are "weakly" typed (type checked when they are instantiated). In C++ it is trivial to write templates that will never type check when instantiated, while in Rust this is impossible.

>> Wrong.

>Indeed, thanks for the correction!

Sorry for the brusque response, I had a "someone is wrong on the internet moment".

>Rust generics are strongly typed (definitions are checked), while C++ templates are "weakly" typed (type checked when they are instantiated).

True. The usual solution is to force-instantiate them against archetype classes. While it is not perfect it is a good approximation.

> True. The usual solution is to force-instantiate them against archetype classes.

This is correct, but you not only need to make sure that they accept an archetype class, you also need to make sure that they reject all others.

This often requires writing and instantiating a substantial amount of code for testing purposes, which often ends up as large or larger than the actual logic itself.

I suppose you already know the pain of doing this, but for those who do not, it is like testing a function in python for all possible inputs. Can be done, but is a lot of work.

In practice, most generic C++ code is not tested in this way due to how painful it is to do so.

So what in Rust takes no work, takes a huge amount of effort in C++.

I have programmed in something like 12 langs, and yes, the first 2 months of rust was kind of brutal to me.

But a lot of it is UNLEARN. Before, I was doing mostly F# and believe back then I was a very functional developer, but now with rust I do more functional programming than before.

Most of time, errors and problems show up because rust is trying to put you towards a way to design the code. The most you fight it, the harder is.

I think, 90% of time rust is right. Doing ERP-like work I say rust is even more productive than F#, that was also great to me.

--

Rust get truly hard when try to do pseudo OO, trying to do introspection (the harder stuff I think), and mix mutability inside the same struct. But most of that happend outside regular development (I'm building a toy lang and hit the hard stuff often)

This article is probably not aimed at Rust beginners and you shouldn't shy away from Rust, if you feel that you cannot possibly ever understand the lifetimes. The perspective of the article seems to stem from the author's own learning process, and might make sense only after you have some experience with the borrow checker and lifetimes. Most of the time everything might go smoothly, when you know the basic rules, but when the compiler gives you an error message, and you think it shouldn't have, then reading the article might give some insight on the problem.

And the Rust developers indeed deserve respect in my opinion too. They are trying to solve a hard problem and not taking the worse-is-better-option.

In a way, it's liberating. Look at it as a service the compiler offers, where lifetime errors are a normal part of the development cycle.

I use rust and I don't worry about the lifetime stuff. Just hack away and get the job done. Overall, rust is lower startup friction than most of the tools I use (though YMMV).

Don't let it, I've only skimmed it but I think you can get started and write some effective rust without even having or understanding the misconceptions.

And even if you did gain a misconception, so what, apparently you'd just be joining other people writing rust who share the same one.

It depends on your background.

If you come from C/C++ then all the notions discussed should be familiar to you, because you used to do the borrowing and lifetime management manually, or you were doing something really wrong. :)

Whereas the rust compiler helps you with all this (super hard and annoying) stuff.

I read this article with caution. I don't want to upset the delicate balance that is my intuition of how the borrow checker works. Articles that say "Don't think of it like X" are double edged swords ;-)

In reality, though, while it took me a while to get relatively comfortable with the borrow checker (much longer than I expected as an old school C++ programmer), 99.9% of the time it works exactly as I expect. Of course the other 0.1% of the time takes a lot of my energy ;-)

Tbh, I'm not sure that reading a list of falsehoods is the best introduction to actually programming in a language.