Rust Interior Mutability - Sneaking By The Borrow Checker

What makes you want to use MacOS instead of something like Linux?

You reffer to Cell, Refcell, Mutex and RwLock as smart pointers, but they are not pointers. The value stored is stored as part of the Cell/Refcell/Mutex/Rwlock not in a seperate location on the heap.

Also while you can't use get on a cell containing a non-copy type, if your type implements Default (as for example String does) you can use take. So you can write code like.

let tmp = cell.take();
// do something with tmp.
cell.put(tmp);

This was so helpful!

Thanks a lot. Really appreciate your high quality videos

You are so good at explaining these! Your rust content is the best out there! <3

@codetothemoon Great video! And I loved you doom emacs setup, would you mind sharing your dotfiles?

In the end, the Node struct ends up with various smart pointers on different fields. I understand we got there by construction, but I wonder if there’s a way to refactor it so that the smart pointers are just on Nodes, rather than the internal fields? Could the add_urgency() function somehow lock an entire node rather than the internal field? What would that look like?

I like using cell for non-copy types too.
Doing `let mut contained = cell.replace(String::new());` allows you to take the string out of the cell, and it can be put back with `cell.replace(contained);`

Can You give an use case of Cow Smart pointer?

Thanks! Excelent content

Short and sweet. Thank you!

i have watcched so many videos about RefCell and Rc and what all tutorials fail on is that no one shows a real world problem applying Rc or RefCell. Every one builds these simple basic graphs that is not applicable on a real life problem. My suggestion to you is that in your tutorial you set out to solve a specific problem instead, that can only be solved by using interior mutability, instead of building this fictional simple graph. Just some feedback.

Yep, probably not going to become a Rust dev

but they are slower than if there's no unsafe code at all... there's performance hit even for the simplest cases just because we can't express things clear enough... or I'm wrong..

At the time this videos made or because of Allan Turing?

Good for me, but not for thee 😏

Nice and crispy video just too fast for me

How and why Arc<> is a costless abstraction?

holly f this is complicated !!! :(

Long story short, bad language design which was intended to "keep you safe" makes your job more verbose and annoying. I'd rather have competent programmers use my language than have to teach users with the compiler the basics of how a computer works. It should be do as you learn, not learn as you do.

I can understand why people love this language but if I don't need the performance I prefer living with a GC. The hoops this throws are just crazy just to implement a simple graph structure..

Wow! This is so informative and easy to follow, although it's a complex topic for beginners like me! Great job

Wonderful!

Great content 🙂👍

Great content, and I like your "no bullshit" style. Subscribed!

You are awesome !

Merci !

I enjoyed this video. I had some trouble understanding Cell and Refcell, and this video is beneficial to clarify these concepts. I think the example you have chosen is excellent because simple enough to focus on the concepts and not be bothered understanding a complex code. The explanations are also really clear, so thanks for sharing this content. That is an excellent job.

I am just feeling wrong passing a non-mutable node but in the function change its members... Is that legit?? It seems like a codesmell

If you're looking for topics, I think a nice related topic (regarding graphs) is IndraDB would be a great one. I never really had a need for a graph database yet, but I'm sure I will at some point, and would be cool to know an open source rust graph db.

If I had seen this video existed a month ago, it would have saved me from spending a whole day banning my head into a wall.

Very helpful video! I think this will come in handy with converting some C++ code to Rust, as it might be safe but just harder to express with the borrow checker.

My interior mutability game has been pretty clumsy. This helped a lot. Perfect level of detail, and the end-to-end explanation of how the pieces relate was just what I needed to shore up my understanding. Thanks for doing what you do.

Wow, very neat explanation! 👍

Very very nicely done. Kudos.

I think it's worth pointing out that interior mutability should be seen as kind of a last resort. I say kind of because obviously there are plenty of situations where it's the right choice - but frequently it's used as a crutch to use Rust just like you would a garbage collected language, when just a slight change in how we think about memory or control flow would lead to better results. That's probably the hardest part about really learning Rust, but the cool thing is that once you get the hang of it, it's easily applied to other languages as well and tends to lead to better project structure.

Great video as always, I was wondering since I'm rewriting my neovim config from zero, what color scheme is this?

One thing is that in rust you should first try to change your API, so that you don't need interior mutability, if that doesn't work only then should you consider using it.

One of the greatest benefits of Rust is that it makes you uncomfortable using worse patterns.
Sure, you can implement it as a traditional graph, but you could also implement it as an entity component system with a vector of nodes and a vector of relationships between them.
That makes it:
1. Memory safe
2. Cache-friendly
3. Without the overhead of reference counting
I'm not saying people should not use RefCell, but people should ask themselves: Do I need it? Or do I want it because that is how it's done in C++/java/...? And is there a better pattern?

One of your assumptions for the use of borrow_mut is incorrect: you assume that there would never be two borrow muts in your add one function, but the cycle case would create a borrow_mut for each loop of the cycle.