Visualize Ownership and Lifetimes in Rust (opens in new tab)

The borrow checker and lifetimes aren't simply a matter of performance, they are a matter of correctness. Languages without them (go, java, etc) allow for bugs that they prevent - dataraces, ConcurrentModificationException, etc. The fact that you can only write through pointers that guarantee they have unique access is what lets the language statically guarantee the absence of a wide category of bugs, and what makes it so easy to reason about rust code as a human (experienced with rust). You can't have that without the borrow checker, and without that you lose what makes rust different (it would still be a fine language, but not a particularly special one).

You could simplify rust slightly by sacrificing performance. For example you could box everything by default (like java) and get rid of `Box` the type as a concept. You could even make everything a reference counted pointer (but only allow mutation when the compiler can guarantee that the reference count is 1). You could ditch the concept of unsized types. Things like that. Rust doesn't strive to be the simplest language that it could be - instead it prefers performance. None of this is really what people complain about with the language though.

Ownership isn’t an advanced concept. It is a software engineering problem, not a rust problem. Rust is one of the few languages which make it explicit and even checkable at compile time and the first popular one.

What is hard is designing systems in a way resource ownership can be tracked and controlled without impacting performance. Rust makes it possible, but you can use smart pointers to give up speed and take simplicity instead. Most other languages assume (rightly so) you’re too dumb to do it correctly and give you smart pointers by default; some assume you’re smart enough and are proven wrong all the time (this is assembly and C relatives; actually they say ‘we don’t want smart pointers and we want a simple compiler, sucks to be you’).

I've tried to wrap up my philosophy on how a significant chunk of rust code can be written without lifetimes using shared and sharedmut primitives.

I've shipped three projects on it and they are pretty much as performant as they can be. I've never regretted skipping the lifetime work in application code.

https://github.com/mmastrac/keepcalm

I still dig into lifetimes for a lot of true low-level code but it doesn't need to exist at all at the high level

That article on rapid Rust prototyping matches my experience with using Rust as the backend for a web and iOS app. I used clone() and Vec and String and other shortcuts from that article as much as possible since I was building a backend application versus an operating system. It enabled a lot more velocity and made it fun to add features. And it was still blazing fast.

If anyone is considering using Rust and is nervous about lifetimes and bare metal, check out that article and try its guidance. I learned these things on my own the hard way and would have loved to read this article 18 months ago. It's really quite good.

> How many of those advanced concept in Rust such as borrow checker & lifetime could be avoided as a beginner?

As a beginner, you can avoid references (&) and simply clone() everything when it gives you trouble. If you start off by writing simple Actix/Axum web services instead of manually multithreaded apps, the problem domain is inherently linear and you'll avoid lifetimes and the borrow checker almost entirely. This lets you feel productive while getting a feel for the rest of the language features.

Don't do this once you learn the ropes of the borrow checker, of course. Once you grok it, the borrow checker is almost second nature.

I think you will run into the borrow checker pretty soon, because you have to deal with it whenever you deal with references (which you will inevitably have to do if you are dealing with anything more complex than number types). But that aspect of the borrow checker is not that difficult. You could avoid it entirely by cloning everything but IMO it's not necessary and you would do better to invest a small amount of time in understanding why the borrow checker is complaining.

Lifetimes you can probably get further without having to deal with. Just avoid storing references in structs and you will avoid a lot of lifetime headaches. Cloning can again be helpful here.

An alternative to cloning everything, if you are dealing with simple data types, is to derive copy for your structs so you can pass them around without worrying about ownership. It's not always possible though.

Smart pointers are another workaround, as others have said. But my problem with (some) smart pointers is that they simply move the checks to runtime, meaning now your code has a much higher chance of panicking at runtime.

The places where you'll usually see lifetimes creep in where you may not expect are in closures (say your app is one big struct, you call a library function that takes a callback, you reference &self in the callback and get an error that the arg type must be 'static, or some other bound), or if you're spawning async tasks and using locks you may get weird Send/Sync and lifetime errors around await and spawn points.

They all make sense if you know why the program doesn't compile, but it may be surprising to newbies.

You can skip lifetimes in the beginning, and I think that's the sane thing to do, if you come from a GC languages.

Borrow checker, well, this actually includes lifetimes. But let's say "basic ownership and basic borrowing", there is no way around starting with that, and it should be a point to learning rust.

You can Arc<Mutex<T>> your way out of ownership/borrowing. At some point, you'll start to see your program as just data (and functional programming will make sense as the only way to program) moving around. I think it's an under-rated way to get started (I started that way) and at some point a bulb will light up and you'll start seeing programming as data moving around and you'll care about ownership/borrowing at the foundational/prototype level.

Yup, that’s definitely correct in terms of avoiding most of the complexity. The tips in that blog post can apply to third party libraries, but sometimes the complexity of the lifetime can leak past the API boundary in a way you can’t ignore (but often you can).

None. And lifetime elision and other forms of pretending to beginners that they don't exist are why so many people have trouble with Rust.

... just write Java/Python/JS, then? Or Kotlin, Typescript, Python+type annotations if you're feeling more modern.

There's nothing wrong with any of those languages (mostly) and not everything has to be written in Rust. IMHO the real value of Rust is as a systems programming language that's safer than C.

Rustrover can do this, although unfortunately it requires cargo check/clippy turned on rather than being native (still faster than LSP, at least).

https://www.jetbrains.com/help/rust/rust-external-linters.ht...

A family of these plugins would be a true killer app for Rust beginners.

New features aren't usually considered breaking changes, only modifying existing ones so that old code doesn't work.

The rust compiler never strives to never introduce breaking changes (by the definition I just described). It doesn't quite succeed (because some things like correctness are considered more important), but it fails

a) Very rarely, not once every 3 months.

b) In very small ways, that only break a tiny portion of code.

c) In ways that are very easy to fix.

d) Usually the rustc-devs will go offer patches to the entire open source ecosystem before any such release.