Rust's Alien Data Types 👽 Box, Rc, Arc 

I was just thinking about this at the beginning of the video. Heap and stack are just different areas of the same system memory. What matters here is that the stack is used to keep the "frame", i.e. all the values that are local, to the current function. This is how, after a function call returns, local variables retain their values, and this is what makes recursion possible. This stack behavior is implemented by keeping a pointer to the "top" of the stack and, on each function call, moving that pointer by an amount equal to the size of the new function's stack frame. That's why the compiler needs to know the size of the stack frame, and consequently, the size of any local variable to a function. Every other object that's dynamic in nature, or recursive, will have to live outside the stack, i.e. using Box. And like you just explained, deallocating on the stack is quite fast, since things aren't really "deallocated", the Stack Pointer is just moved back to where it was before the function call, while allocating and deallocating on the heap usually involves interacting with the Operating System to ask for available memory. Great video! Keep it up!

I think "stack is faster than heap" is a pretty reasonable starting point, especially for a talk that isn't going into nitty gritty details about allocators and caching. Stack memory is pretty much guaranteed to be in your fastest cache, but with heap memory a lot depends on access patterns. If you have a really hot Vec then sure, there's probably no performance difference compared to an array on the stack. But for example a Vec where each String has its own heap pointer into some random page, isn't going to perform as well.

@@oconnor663 For most programmers that aren't going down the nitty-gritty sysprog hole the assumption that "stack is faster than heap" covers 95% of all use-cases. The msot time spent when dealing with memory is allocating and deallocating after all.

You'd need to set another register than EBP but the type of memory is indeed exactly the same, and the cache will cover both. But there may be system calls when using the heap. "In an ideal world you'd have everything on the stack" - I disagree if that's in the absolute, bear in mind the stack is limited in size and if you cannot often control what was stacked before your function is called or what will be stacked by the code called by your function. It's not appropriate for collections either because it would complicate size management and cause more memory moves (which are very power-consuming). But I think you meant it otherwise, for small objects in simple cases where this isn't a concern. These days memories are so large that people tend to forget about those limitations and then they are surprised the first time they have to deal with embedded code. ;-)

It makes total sense, both are in RAM. The thing is the stack is contiguous so writing to it is fast because the writes are sequential, while the heap is probably fragmented, which means random writes. Edit: without taking into account what the others have said, about frames, OS allocation, etc, everything contributes.

Thanks for the kind words Miguel! It's thrilling to know that these videos can make these concepts a bit more palatable.

​@codetothemoon, the way you described lifetimes just clicks

Nice, I'm so glad you found that perspective valuable!

Nice, I've put it on the video idea list!

As far as I can see, if your implementation requires RefCell then your implementation is probably wrong. ;)

Nice, glad you found it valuable!

The rust book teaches like he did, Rc::clone(&an_rc), i think the reason is just to be idiomatic. Nice to know both ways are fine.

thanks for the kind words, really happy you got something out of the video!

Nice CJ! Glad you found it valuable - more to come!

Thank you gorudonu! More on the way, and I've put FFI/unsafe on the video idea list.

Glad it was helpful!

Thanks Ramkumar, so happy it helped you!

Thanks and thanks for watching Jos!

Haha! Seems like there is a lot of desire for RefCell, I've placed it high on the video idea list.

Thanks so much for your support Fotis!

Thanks Namaste (amazing name btw!), glad you found it valuable!

Thanks for watching, more to come!

thanks for watching!

Thanks!

Great, that's precisely what I'm aiming for! Glad you found it valuable!

thank you!! 😎

Seems like we have a few requests for Cow, I’ve added it to the video idea list!

@@codetothemoon thanks!

Thanks for watching!

Thanks Gavin! Impressed you noticed the 60fps ;)

Thanks and thanks for watching!

glad it was helpful!

Glad you found it valuable, thanks for watching!

thank you, glad you got something out of it!

glad to hear, thanks for watching!

Thanks and thanks for the feedback! Touching on ordering was probably a little confusing, to your point I probably could have just mentioned the different counter types, and that one is thread safe while the other isn't

thanks, glad you liked it!

nice, really happy that you found it valuable!

Glad you found it valuable, thanks for watching!

nice, glad you found it valuable!

Thanks Thorkil, glad you liked it!

thank you so much!

I misspoke on this - thanks for pointing it out! I made a pinned comment about it.

I excluded it from this video to keep things concise, and I wasn't convinced it would be useful for the vast majority of folks. But several people have requested I cover it, so I may at some point. In the meantime there is coverage of it in one of the later chapters of the Rust book.

Thanks Brandon!

ohh nice thanks for the pointer (no pun intended) !

Thank you too!

Julian - that's fantastic! It thrills me to make tough concepts more palatable.

great, really happy you got something out of the video! I don't have a video specifically on deciding how long a piece of data should live for, but "Rust Demystified" does cover lifetimes.

Thanks Tsiory, very happy to have you onboard!

they are singletons - when we call clone on the Rc/Arc smart pointers, it's the pointer that's being cloned, not the underlying data

@@codetothemoon That you can do it is not the point.

thank you, glad you found the video valuable!

How so? I thought C# uses garbage collection as opposed to reference counting?

@@codetothemoon I didn't mean on the memory allocation part, more so of how reference types work in C#

Got it! Yeah my understanding was that stack memory is more likely to be stored on the CPU cache - but maybe that's possible for the heap as well... Though I haven't actually benchmarked this, maybe I'll do that...

Ordinary variables could also be assigned by the compiler to CPU registers, which makes them as fast as they get. This doesn't happen to the heap-allocated variables.

@@codetothemoon Access is fastest when the data is "near" the recent access. Which is a part of why data oriented programming is so much faster. but I bet the methods of memory access have changed so much that what we are taught is not what is implemented in the most recent technology

awesome, glad you got some value out of it!

thanks modolief! I'd thought about creating a little intro reel, but every time I consider it I conclude that it would hinder my mission to provide as much value as possible in as little time as possible

@@codetothemoon The channel "PBS Eons" also has a really good intro bit. They start their video, then at around 20 or 30 seconds they give their little imprint. But what I really like about it is that even though it's more than about 3 seconds it fades out quickly, and they already start talking again before the sound is done. Very artistic, yet not intrusive.

It's short, which I like, but the sound is kind of jarring.

they are a rite of passage every Rust developer must traverse.... 😎

thank you!

Thanks I shall continue!

nice, it seems like many JS frontend devs are interested in Rust!

Sure it's Dark+!

@@codetothemoon Thanks! Have changed my theme.

that's correct! Rc doesn't really help much if you intend to hang on to one reference until the program ends - you could just use regular borrows in that case - but in this example to show the strong_count function I just kept a reference in main.

Thanks, will do one eventually, wishing I had done it for Halloween as I think it has the appropriate level of spookiness 🎃

Thanks and thanks for watching! VSCode theme is Dark+

Definitely doing this at some point, given the spooky factor it would have been a good one for halloween, but unfortunately it probably won't be ready in time 🎃

I've added RefCell to the video idea list! I've been curious about those frameworks as well, especially Axum.

yeah, now I see the stickied comment

thanks for pointing this out - I should have mentioned this in the video if I didn't!

I have another video for all of these (except UnsafeCell) - check out “Rust Interior Mutability”

Thanks!

I had to look this up - is this what you're referring to? lol areweyeetyet.rs/

Sorry I misspelled. its Yew - gui for rust

@@noblenetdk Oh actually I already have a video about Yew - check out "Build A Rust Frontend" from earlier this year!

great question, in Rc's implementation of clone there is `self.inner().inc_strong();` which increments the strong reference counter. So it doesn't necessarily know where the references are, it just increments a counter each time one is created. Then in Rc's implementation of the Drop trait (which has a drop method that is invoked when the implementor goes out of scope) we have `self.inner().dec_strong();` then if `self.inner().strong() == 0 { /*code for cleaning up memory here */ }`

@@codetothemoon Ohh I see :)) Thanks very much, that makes sense!

🔥

been meaning to make a video about it! stay tuned...

me too!

I've put it on the video idea list!

🚀🌕

Haha thanks!

It's a single-threaded mutex (well, read/write lock.) This might seem useless, but it can be used to create shared references that can still be modified: make an Rc, which you can clone freely, but you can still lock it for mutable writing. (if you try to take multiple write locks at the same time, the thread will panic.) it's sort of like a pointer to an object in a regular OO language. You can also use it to make mutable thread-local data. Keep in mind anything containing a refcell can't be sent across threads. They're also a pain to serialize.

sorry-- RefCells can be sent but references to them can't be sent, and Rcs / references to rcs can't be sent.

RefCell seems to be frequently requested, I'll probably make a video about it! In the meantime it looks like like strangeWaters has a good description, and there is also an explanation in chapter 15 of the Rust book.

Woah

Synchronization is expensive. Complexity in the code, complexity in the instructions, complexities in the CPU itself.

It isn't. You can define circular data with Rc that will never be deallocated. It's the programmer's job to handle this case correctly. This was actually at the centre of the Leakpocalypse. It was decided that, while accessing deallocated memory is `unsafe`, leaking memory isn't. You can somewhat get around this with weak references, to get circular data with deallocation, but it gets complicated pretty quickly.

Yeah, I definitely appreciate that stack vs heap is much more nuanced than I made it out to be in this video...

It’s really challenging. But so interesting. And as I learn Rust I feel as though I am learning very important concepts that are key to becoming a proficient software engineer.

lol nice!

Rc stands for reference counter and Arc stands for atomic reference counter, they are just abbreviations which is good because they are frequently used and imagine writing ReferenceCounter every time, especially when you have to wrap many things with them. For box it could be named better maybe, but there is no type that is going to be called a "box". If it is a math library it would call it cuboid, cube, rectangular prism or something else. For types that are frequently used short names are good.

Totally understand your frustration - to add to the other response, I believe "Box" and "Boxing" are terms that have histories that extend well prior to the inception of Rust, but are usually hidden from the developer by developer-facing language abstractions. I think Rust is just one of the first to actually expose the term directly to the developer.

​​@@codetothemoon Example dated usage: X.Leroy. Unboxed objects and polymorphic typing, 1992. The terms have been used in libraries also, at least since 2007 in Haskell and 2000 in Steel Bank Common Lisp. I suspect it could be traced back several decades more.