The Rust Borrow Checker - A Deep Dive - Nell Shamrell-Harrington, Microsoft

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
The Rust Borrow Checker - A Deep Dive - Nell Shamrell-Harrington, Microsoft
The Rust compiler's borrow checker is critical for ensuring safe Rust code. Even more critical, however, is how the borrow checker provides useful, automated guidance on how to write safe code when the check fails. Early in your Rust journey it may feel like you are fighting the borrow checker. Come to this talk to learn how you can transition from fighting the borrow checker to using its guidance to write safer and more powerful code at any experience level. Walk away not only understanding the what and the how of the borrow checker - but why it works the way it does - and why it is so critical to both the technical functionality and philosophy of Rust.

[@joelmontesdeoca6572]

We need more speakers like Nell!

[@rodelias9378]

Thanks for such an amazing talk, Nell. Well done!

[@therselman]

Excellent, you covered a huge amount of information in 22 minutes. And kept it very concise. Amazing job!

[@seanlestermiranda]

This is amazing, Nell.

[@francopan]

Wow. Just wow. What an awesome presentation!

[@NFLStudy]

Great video on borrow checker. Thank you Nell!

[@gregoryking2664]

This was a very clear explanation. Thank you.

[@ericmink]

That talk was well-made, but I expected more speed and depth from the "a deep dive" in the headline.

[@primingdotdev]

th-cam.com/video/68U8ZZ1EnEQ/w-d-xo.html, this one was useful

[@caseyyeow1649]

Excellent! I thank you too!

[@kbaeve]

Thank you!

[@HumanoidTyphoon91]

The talk was interesting and I learned some things, so thank you, but my level of understanding of the borrow checker... that has changed an extremely small amount.

[@michaelzap8528]

Very important talk

[@glennedgar5057]

Good presentation. When is rustc used instead of c# at microsoft

[@michalkupczyk7]

So when I see Rust "let y=x;" for heap-allocated types, it translates to 'C'(C#, C++) code "y=x; x=null; " ??? The x pointer 'loses' the value, and compiler detects use of that?

[@urbex9797]

No, that's what happens with a C++ move (the "moved from value" needs to be left in a valid state). In Rust, the compiler doesn't have to use x=null;, because it throws a compilation error instead. Think of it as marking the value as "invalid from that point on" in the symbol table of the function (the symbol table is simply a list of a function's variables that the compiler keeps at compile time).

[@Rogueixpresents]

this is Rust not c, u need to learn rust not c, u will never use c, so stop being pretentious and just use modern stack.

[@KevinInPhoenix]

On what planet is an assignment statement (let y = x) a "move" instead of a "copy"? In Rust if x and y are numbers then things work as expected. If they are strings then they don't. Rust has eliminated the memory management from the runtime and moved it into the programmers head. Not a reasonable tradeoff for most programming. I would rather be thinking about the problem domain than the rules of Rust.

[@dv_xl]

Compared to a GC language it forces the programmer to think a lot more sure. However compared to other manually managed memory languages it's simply forcing the programmer into constraints that mean a whole class of very common errors are eliminated.
Allowing stack allocatable types like i32s to copy by default is fine, but creating a copy of a type that contains a pointer to raw heap isn't - within the constraints of rust's memory management

[@megumin4625]

You need to understand why this happens. Rust is helping the programmer manage memory correctly, rather than letting them make memory mistakes which create UB and vulnerabilities. Even if you did this in another language (say C) and it allowed you to do it, it would cause potential unseen and dangerous UB (and you may not even know about it until years down the road).
Copying a number on the stack to another variable is fine. It's a cheap copy, there are no memory vulnerabilities associated with this. However, what happens if you instead copy a heap allocated type instead of move it? You now have 2 variables that own it, and now you will free it twice. Oops. Now you just did a double free.
These are constraints you'd have to fix under any other manual memory management in the first place. The tradeoff exists in any other manual memory management language - the only fact is that it doesn't usually tell you about the problem. Rust just helps you catch it from the get-go.
However, if what you're worried about is memory management and runtime, many other GC languages exist you can use, e.g. Go. There's a performance cost to using it of course. Rust wasn't designed to have a GC - it was designed to have zero-cost memory management just as fast as c/cpp - but not at the cost of accidentally getting it wrong. To get this speed, the tradeoff is that you have to think about these things. But thankfully, since Rust helps with the memory management, you won't have to get it wrong quite as often. So, if your need was a language that manages memory for you, you're looking in the wrong place, since Rust is more of a c/cpp replacement, not a Python/Java/etc replacement.

[@kevinkkirimii]

I still hear dungeons and dragons far inside her voice.