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.
To me, it doesn't look very different to what you need to know about scopes in C++. The only benefit of rust is, that the compiler tells you, where you made an error, whereas in C++, you usually need a sanitizer for that purpose.
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?
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).
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.
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
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.
![CNCF [Cloud Native Computing Foundation]](http://yt3.ggpht.com/txe66EjpkDQQlx_4jDV0yA0PPsww0rqQrFhMpDqagLWN2-EUBBO65IuIyy5tEFVmpI4_RRduzXc=s48-c-k-c0x00ffffff-no-rj)
We need more speakers like Nell!
Thanks for such an amazing talk, Nell. Well done!
Excellent, you covered a huge amount of information in 22 minutes. And kept it very concise. Amazing job!
That talk was well-made, but I expected more speed and depth from the "a deep dive" in the headline.
ruclips.net/video/68U8ZZ1EnEQ/видео.html, this one was useful
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.
Felt like i learnt some things about the compiler but not so much about the borrow checker
Wow. Just wow. What an awesome presentation!
This is amazing, Nell.
To me, it doesn't look very different to what you need to know about scopes in C++. The only benefit of rust is, that the compiler tells you, where you made an error, whereas in C++, you usually need a sanitizer for that purpose.
Great video on borrow checker. Thank you Nell!
Good presentation. When is rustc used instead of c# at microsoft
Very important talk
Is it just me or the video at 16:15 is completely broken?
Thank you!
Excellent! I thank you too!
This was a very clear explanation. Thank you.
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?
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).
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.
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.
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
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.
I still hear dungeons and dragons far inside her voice.