How to fight a `malloc` troll: * Lure it in a cage with some juicy aligned memory * Close the cage * Leave the troll in the cage for an hour or two * Open the cage and `free` the troll * Open the cage and `free` the troll Thank you for your great videos Ryan!
Hands down best explanation of basic Rust concepts. Rust's learning curve is steep, these videos make it way easier to grip basic concepts than book. You saved me days or weeks. Thank you.
this is like gold. First time I understood what the take methods do by motivating it with std::mem::replace. found it a lot easier to follow this video than the book, thanks so much.
Thanks for the video! I fell into that trap of trying to implement a LinkedList as my first Rust project, and it really put me off learning the language any further. I think I'll give it another shot now that I've watched this though.
What a great presentation. Learned a good few neat Rust tricks there even if I never want to write such a linked list. Thanks. I just wrote a little program that generates random mazes like those in the old Hunt the Wumpus game. 20 nodes (caves), three links (exits) out from each, 20 edges (tunnels). After I had done it I realized I had a solution to the linked list problem in Rust. But it was so simple! I just kept all my nodes in an Vec, all links are just indices into the Vec. Like an old school C programmer that did not want to use malloc.
Correct me if I am wrong but linked list should push at the end of the current list. Usually we don't have pop in linked list but if we do its queue basically. This implementation is more close stack.
A question from a newbie: Instead of using Link enum what if we had the Node struct defined as: struct Node { data : T, next: Option } I had been trying to implement from the aforementioned Node struct without any success.
Coming from years and years of c/c++ one of the most interesting aspects of rust is enums. They are different enough from enums in existing languages I almost wish they had been called something else. They remind me of custom types in elm or tagged unions in other languages even ADTs. From the name enum I would not have thought of using them as the LInk type. The level of detail in these streams is great I have learned more in the last couple of weeks from these than in all my reading over the last six months.
Thanks a lot. I have gone your document carefully. Now this youtube link is an added bonus. How to count the length of the linked list - How do you write an iterator for this. Thanks a miliion for your efforts in educating future rust developers
I used you iter and implemented the length - For your feedback pub fn len(self)->i32 { let mut count1 = 0; let mut iter:Iter =self.iter(); loop{ let x=iter.next(); match x{ None=>return count1, Some(_)=> count1 = count1 + 1, } } }
I don't think this is necessarlly a stack thing, even for allocating on heap the compiler needs to know the size of the allocation and computing the size of recursive struct is a non-terminating recursion. People will trip on this if they are comming from reference based languages (like java etc) where everything is a pointer so having a node inside a node means having a node pointer inside a node (and that's what the compiler error is talking about to use box)
Yes this is certainly true that it's not really directly related to the stack. I think my explanation wasn't quite clear. You are correct that the size of _any_ allocation (irrespective of where it is) must be known at compile time and that GCed languages often obscure this because the automatically allocated and deal in references on the users behalf.
A linked list is in the std crate, instead of trying to make one why don’t people just look at the implication there? 🤔🤷. Thanks for the video. I once thought about trying to make an RBTree collection but there is a crate for that too.
The error message is slightly different as well now (it was not not when the PR was first introduced). `todo!()` indicates that you intend to implement it eventually, while `unimplemented!()` can be used for functions that aren't applicable to some implementations, e.g. on a platform that doesn't have some feature.
I know that is interesting structure because of Rust nature, but in current state of hardware (memory x100 slower that cpu and huge caches) using lists should be strongly discouraged, even smarter structures with pointers for N bellow 100 or even 1000 have almost no advantage.
Coming from C I can't stand Rust code. Everything has a weird type. Why do command line arguments need their own type (two actually)? Why do stdout and stderr need to be two separate types? Why are there so many string types that cannot be interchanged? I get having a strong type system but this is ridiculous, and it just doesn't make sense to me. It's memory safety has never been a factor for me writing code either. I've tried to use it, I really have, I tried to love it, But C pulls me back in with its simplicity every time.
I hate this “take” hack coz it’s a hack. The only reason one needs to do it is to satisfy borrow checker. That’s one of the cases where Rust certainly feels awkward and dogmatic Prove me wrong )))
If you’re explaining Rust’s system for borrowing and ownership. Once you know it, it takes around a minute or so. Plus linked lists are almost _never_ used in Rust.
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
How to fight a `malloc` troll:
* Lure it in a cage with some juicy aligned memory
* Close the cage
* Leave the troll in the cage for an hour or two
* Open the cage and `free` the troll
* Open the cage and `free` the troll
Thank you for your great videos Ryan!
choked on my coffee while reading this. lol
a trick: you can watch series at flixzone. Me and my gf have been using it for watching loads of movies lately.
@Moises Alec Yup, have been using flixzone for since november myself =)
Hands down best explanation of basic Rust concepts. Rust's learning curve is steep, these videos make it way easier to grip basic concepts than book. You saved me days or weeks. Thank you.
this is like gold. First time I understood what the take methods do by motivating it with std::mem::replace. found it a lot easier to follow this video than the book, thanks so much.
Need your videos still in 2025, please make more videos. Your channel is one of the best for learning rust
Thanks for the video! I fell into that trap of trying to implement a LinkedList as my first Rust project, and it really put me off learning the language any further. I think I'll give it another shot now that I've watched this though.
What a great presentation. Learned a good few neat Rust tricks there even if I never want to write such a linked list. Thanks.
I just wrote a little program that generates random mazes like those in the old Hunt the Wumpus game. 20 nodes (caves), three links (exits) out from each, 20 edges (tunnels). After I had done it I realized I had a solution to the linked list problem in Rust. But it was so simple! I just kept all my nodes in an Vec, all links are just indices into the Vec. Like an old school C programmer that did not want to use malloc.
Simply amazing man, the way u explained the diff between & and Box and the lifetimes, Thnx a ton.
Very informative Rust content you put here. I appreciate!
Correct me if I am wrong but linked list should push at the end of the current list. Usually we don't have pop in linked list but if we do its queue basically. This implementation is more close stack.
This is a linkedlist implementation of stack
A question from a newbie: Instead of using Link enum what if we had the Node struct defined as:
struct Node {
data : T,
next: Option
}
I had been trying to implement from the aforementioned Node struct without any success.
Is there any plan to do the same livestream for Graph data structure? If not then thats fine :) just curious
I was considering doing a doubly linked list, but a graph could also be interesting!
@@RyanLevicksVideos please do a video on double linkedlist
Coming from years and years of c/c++ one of the most interesting aspects of rust is enums. They are different enough from enums in existing languages I almost wish they had been called something else. They remind me of custom types in elm or tagged unions in other languages even ADTs. From the name enum I would not have thought of using them as the LInk type. The level of detail in these streams is great I have learned more in the last couple of weeks from these than in all my reading over the last six months.
This sent me down a rabbit hole regarding tagged unions and c++17 feature variants which are similar but not so much.
They’re exactly ADTs.
Thanks a lot. I have gone your document carefully. Now this youtube link is an added bonus. How to count the length of the linked list - How do you write an iterator for this. Thanks a miliion for your efforts in educating future rust developers
I used you iter and implemented the length - For your feedback
pub fn len(self)->i32 {
let mut count1 = 0;
let mut iter:Iter =self.iter();
loop{
let x=iter.next();
match x{
None=>return count1,
Some(_)=> count1 = count1 + 1,
}
}
}
@@MukkaiKrishnamoorthy you could have just use self.iter().count()
Would it not be possible to leave new_head's next value as None, assign self.head to new_head and then assign old_head to new_head's next?
51:56 -> Hello from future!
Can we use Refcell instead of Box
self.head.take() , always make head = None , so how next_node point to previous ?
I don't think this is necessarlly a stack thing, even for allocating on heap the compiler needs to know the size of the allocation and computing the size of recursive struct is a non-terminating recursion. People will trip on this if they are comming from reference based languages (like java etc) where everything is a pointer so having a node inside a node means having a node pointer inside a node (and that's what the compiler error is talking about to use box)
Yes this is certainly true that it's not really directly related to the stack. I think my explanation wasn't quite clear. You are correct that the size of _any_ allocation (irrespective of where it is) must be known at compile time and that GCed languages often obscure this because the automatically allocated and deal in references on the users behalf.
Hi Ryan, thank you for providing awesome rust contents in your channel. Where/how can I view the livestream version of it?
Thanks for the great video
52:00 Hello from the future
I learned a lot in this tutorial to the point that I got hungry hahaha.
A linked list is in the std crate, instead of trying to make one why don’t people just look at the implication there? 🤔🤷. Thanks for the video. I once thought about trying to make an RBTree collection but there is a crate for that too.
what's the difference between todo! and unimplemented! ?
They're the same thing. `unimplemeneted!` was introduced first and `todo!` was introduced later. `todo!` is shorter and so I always use it.
The error message is slightly different as well now (it was not not when the PR was first introduced). `todo!()` indicates that you intend to implement it eventually, while `unimplemented!()` can be used for functions that aren't applicable to some implementations, e.g. on a platform that doesn't have some feature.
I know that is interesting structure because of Rust nature, but in current state of hardware (memory x100 slower that cpu and huge caches) using lists should be strongly discouraged, even smarter structures with pointers for N bellow 100 or even 1000 have almost no advantage.
Coming from C I can't stand Rust code. Everything has a weird type. Why do command line arguments need their own type (two actually)? Why do stdout and stderr need to be two separate types? Why are there so many string types that cannot be interchanged? I get having a strong type system but this is ridiculous, and it just doesn't make sense to me. It's memory safety has never been a factor for me writing code either. I've tried to use it, I really have, I tried to love it, But C pulls me back in with its simplicity every time.
TBF, writing an echo in one line made me feel very happy, ignoring the gigantic 3.7MB the binary was.
**&straighforward
I hate this “take” hack coz it’s a hack. The only reason one needs to do it is to satisfy borrow checker. That’s one of the cases where Rust certainly feels awkward and dogmatic
Prove me wrong )))
so i need 1 hr to create a linked list in rust🤔
If you’re explaining Rust’s system for borrowing and ownership. Once you know it, it takes around a minute or so. Plus linked lists are almost _never_ used in Rust.