[gnuvince]

If you don't mind a bit of a re-education, Rust allows you to write programs that are as fast as those written in C or C++ and you'll be more confident that they don't have strange memory bugs. (Reason: the ownership model of Rust prevents a lot of bugs that are found in C or C++, but this model also rejects many correct programs, so you need to re-learn how to write some programs.)

[wwright]

One thing people (like me ) often say is that it forces you to “learn to write better.”

One way you can think of it is this:

- Rust rejects some programs that are truly wrong (`“2” + 3` style)

- Rust rejects some programs that really are just fine. They are actively improving this with stuff like “Non-lexical lifetimes.”

- Rust rejects some programs that are fine _how they are now_, but which are hard to keep fine when you change them. This is part of why linked lists are hard to write in Rust :-)

[gnuvince]

I admit that I'm very unexcited about non-lexical lifetimes—the cost-to-benefit ratio seems worse than the current model. The current lifetime system is simple to understand: a value is live until its owning variable goes out of scope. It can be a bit restrictive sometimes (though it seems that after a while you learn how to work around those issues easily enough), but it's easy to keep in your head and reason about code. With non-lexical lifetimes, I think that we'll have a harder time understanding lifetimes, it'll be more difficult to teach them and to debug them.

[wwright]

My understanding is that the semantics are exactly the same, but it’s just possible for the checker to match your intent more tightly.

For example, in lexical lifetimes, this fails:

    let x = &mut foo;
    
    if x.bar() {
        baz()
    } else {
        foo.consume() // takes foo by value
    }

It will complain that you’ve used `foo` while it is borrowed by `x`, even though a human can easily tell that `x` is already irrelevant by that point. NLL would accept this (I believe).