Rainer Stropek - Memory Management in Rust

Рет қаралды 9,806

4 ай бұрын

This session is for people who are rather new to Rust or who are curious about why so many developers are passionate about the programming language. It aims to unravel the unique facets of Rust's memory management, including Ownership/Borrowing, Stack/Heap allocation, Reference Counting, and Lifetimes. Rainer will present a similar session at the upcoming OOP conference, so this is kind of his rehearsal.
Source: github.com/rstropek/rust-samp...

Пікірлер: 25

@millerjimd 4 ай бұрын

I appreciate you defining who the expected audience is and the general expectations at the beginning.

@budiardjo6610 4 ай бұрын

this is the best explained, especially using assembly

@ArmandoDoval 4 ай бұрын

When you're talking about Rc and multiple ownership, I don't like "you need synchronization" as an explanation for why mutable borrows are forbidden. That's not an issue in a single-threaded context. The real reason as I understand it is that Rust wants to guarantee that while you hold a read-only reference, the data it points to won't change. This is a useful property both for humans trying to reason about the program and for the compiler to make optimizations (if you can alias a mutable reference, the compiler has to assume writes might've changed data pointed to by read-only references.)

@olafschluter706 Ай бұрын

It is more than that: even in single-threaded applications there is the problem of "spooky action at a distance" in C and C++, where some part of a program alters things through a totally different path to the data than another part - and, as there is this "cast const away" on function parameters in C and C++, surprisingly within a function or method taking a const reference. Then there is async - absent in C and IIRC only planned for C++ - where a single thread acts on a list of tasks in turn, suspending a task if it is awaiting another async task to complete and turn to the next. Concurrency and parallelism is where Rust runs circles around C and C++.

@flwi 3 ай бұрын

Wow, this was a great presentation! I just started learning rust this month learned a lot by this look behind the scenes. Well done!

@Element_Finland 4 ай бұрын

Loved this! I really enjoyed the enthusiasm.

@psykomal2744 4 ай бұрын

I think the last part of multiple &mut not showing an error is because RefCell does borrow checking at runtime and not compile time

@rohelFR 2 ай бұрын

Yes, exactly

@greenspand 4 ай бұрын

Am just starting up with Rust, thank you was a great talk.

@jooonmantv 6 күн бұрын

Amazing video

@eugenius7371 4 ай бұрын

Me favourite type of teaching

@peter9477 4 ай бұрын

At 5:36 you said it was allocating on the heap when you meant the stack (rsp adjustment).

@saiyanrivals 4 ай бұрын

It was amazing :)

@basado_definitivo 4 ай бұрын

yess!

@meowsqueak 3 ай бұрын

@rstropek, can you please explain what went wrong with the last demo, now you’ve had some time to reflect upon it? Edit: ah, you explained at 53:30, although I don’t think you should have borrowed from the samwise *copy* since I think you wanted to demonstrate multiple mutable borrows from the *same* RefCell, which would have been Frodo’s.

@CrapE_DM 4 ай бұрын

I'm just before the "multiple owners" section, so I'm pretty sure you don't cover it: When you transfer ownership into a function argument, does it copy the data into there? I assume there's no version of referencing at that point.

@bolt7 4 ай бұрын

Unless it's a Copy type, no. Ownership is a zero-cost abstration. It only exists at compile time, and the compiler is smart enough to only copy data when it has to.

@olafschluter706 Ай бұрын

Unless the passed type implements the Copy trait, the data is passed into the function by reference (as in C++), and the caller has no longer access to the data (as not in C++) - this means it was "moved" and ownership was transferred. So the rule of thumb here is: ownership changes if a type does not have the Copy trait (this is true for assignments of one variable to another as well). If it has (like for all scalar basic types in Rust like integers or floats), then the called function receives a copy of the argument (it is still possible to pass a reference of such a type into a function, and if the function takes it as a mutable reference, the function can even alter the data with the caller seeing it). The Copy trait has the semantics that if you do a memcpy of that type to a different memory area you obtain an independent copy of all data contained. Types that contain references to other data cannot implement Copy. They may be able to implement Clone, if all their parts implement Clone. Clone is expensive, it is a deep copy of a data structure. Clone is never invoked without the programmer explicitly calling for it. Whereas Copy is.

@alexpyattaev 4 ай бұрын

You are inconsistent with respect to c# guys - their struct objects are stack allocated. Also destructors in c++ work pretty much same as in rust, except for the move semantics. Would be nice to make distinction clear there.

@metaltyphoon 4 ай бұрын

Yeah, you can also stack allocate an array with stackalloc keyword