This makes completely logical why some things must be Box<>'ed and borrowed. Why you cannot treat Trait or even impl Trait like any other type. Why sometimes it's ok to have impl Trait as your return type while in other cases it's impossible and you must Box<> it.

Third important realization is that things borrowed out of containers might be moved 'behind the scenes' by the container while you hold the borrow, so you are not allowed to mutate container while you are holding borrows to any of its contents. So it's ok, to instead hold indexes or copies or clones of keys if you need.

Another observation is that any struct that contains a borrow is a borrow itself. Despite using completely different syntax for how it's declared, created, it behaves exactly like a borrow and is just as restrictive.

Last thing are lifetimes, which don't have consistent (let alone intuitive) syntax of what should outlive what so are kinda hard to wrap your head around so you should probably start with deep understanding what should outlive what in your code and then look up how to express it in Rust syntax.

Rust is syntactically very similar to other languages, but semantically is fundamentally different beast. And while familar syntax is very good for adoption I'd also prefer tutorials that while showing the syntax explain why it means something completely different than what you think.

I found it frustrating enough that I put the language down and just went back to using C++.

You can ignore that in other languages, but this comes at a cost later.

Joke btw. That thread is a hilarious trainwreck - surely the final nail in the coffin for the Rust advocates who so often deny anything about Rust is difficult to learn.

I don't mean that as an anti-Rust jibe, in fact I'm planning to get back to it this year (having given up in despair last). I like much about it, and think it's tremendously practical for many purposes. But it just is a difficult language, no question.

(They seemingly don't use more apt comparisons with OCaml and Haskell, for instance, not expecting the reader to know them.)

1. "Operators" have different meanings. `1 | 2` and `1..=2` mean something different in patterns than in expressions. Here is a silly example: https://rust.godbolt.org/z/76Ynrs71G

2. Ambiguity around when bindings are introduced. Notice how changing a `const` to a `let` breaks the function: https://rust.godbolt.org/z/aKchMjTYW

3. Can't use constant expressions, only literals. Here's an example of something I expect should work, but does not: https://rust.godbolt.org/z/7GKE73djP

I wish the pattern syntax did not overlap with expression syntax.

fn func<'a>() means that 'a must outlive execution time of func

but

T:'a means that references contained in T must live longer than 'a

and

'a:'b means 'a must live longer than 'b (that's consistent at least)

Maybe:

    fn 'a:func() {

    fn func() 'a:{

Maybe some directional character would be better than : (> is probably out of question because of <> generics)

----

I feel like structs that don't have 'static lifetimes because they contain some borrows should have it indicated in their name.

For example:

    struct Handle&<'a> { n:&'a Node }

    struct Handle&'a { n:&'a Node }

    struct Handle& 'a:{ n:&'a Node }

Then you could use it:

    let h = Handle& { n: &some_node };

Like

    vec![].into_iter().map()

    vec![].iter&().map()
    

Not sure if it would also be nice to differentiate structs with &mut

----

I would just like to separate lifetimes syntax from generics syntax because those two things have nothing to do with each other from the point of view of the user of the language.

----

I would also like to have

while cond {} else {}

where else is only entered if cond was false from the start. But that's a wish not specific to Rust.

That you can write very few interesting programs without venturing into the heap with Box, Rc and such and into internal mutability with Cell and RefCell.

Then it quickly raises to the power of other languages and surpasses them with "pay for only what you use" mentality.