Thanks for the Rust code. I prefer Go for its simplicity. Below is a Go version of your program that walks the list and prints the values: package main import "fmt" type listNode struct { val int next *listNode } func toList(vector []int) *listNode { var cur *listNode for i := len(vector) - 1; i >= 0; i-- { newNode := &listNode{vector[i], cur} cur = newNode } return cur } func main() { var vector []int = []int{0, 2, 4, 6} cur := toList(vector) for cur != nil { fmt.Println(cur.val) cur = cur.next } }
This is such a nice explaination, one of the best I've see. I am coming from C/C++ so you saying things Box is just a smart-pointer make alot of sense to me :)
@@zwhitchcox Wow you did really well I've been using rust longer (not by much) but got tripped up trying to do the linked list and found your videos. Thanks I had trouble figuring out how to link all of them and follow the mutability rules.
Actually, linked lists in Rust are trivial -- you just use an already available implementation. They are only hard if, for some reason, you feel a need to re-invent the wheel. Perhaps you used them a lot in C, where you HAVE to implement them yourself by putting pointers in structs and keeping them up to date, and for some reason you would like to see what it's like to do the same thing in Rust. That's not something you NEED to do, or SHOULD do, or even would be PERMITTED to do when contributing to a real project -- it's just you screwing around, writing code you SHOULD DEFINITELY NOT USE, in order to recreate your C experience in Rust. The linked list code you really want to write is absolutely trivial, more trivial than in C -- you just use the API for the appropriate linked list implementation. And you don't have to test it; it has been separately tested, and it works. By the way, linked lists were popular in the 80s, when microprocessors didn't typically have caches, but they are cache destroyers since entries are typically going to be in different cache lines. Arrays / Vecs / VecDeques are much more cache-friendly, and allocating/deallocating an entry is much cheaper, so they are often more performant even if you sometimes have to copy entries. And there are a lot of other data structures to choose from. So where performance (or memory) is a concern, a linked list might not actually be a good idea in the 21st century -- there is almost always a more performant way to get the same job done. I think it's important to be clear about this, since people seem to get triggered about how how much they have to learn in order to reinvent linked lists in Rust -- something it would make no sense to do for anything real.
its a exercise. I wont ever need to write a production version, sure. but doing it once makes sure I understand the rules properly. By the way it is incorrect to say linked list cause cache misses. Just batch allocate the nodes.
Again, the point is that some people think that this means something terrible about Rust, because they re-implement linked lists over and over again in their C programs and naturally think that they'll need to do the same in Rust. They will NOT. I have no problem with doing this as an exercise, as long as it is accompanied by the clear explanation that this is not actually useful, not something anyone should do. If you DON'T explain that, then you just add to the erroneous impression that people need to write their own linked lists in Rust like they do in C, and goodness look how hard it is, so omigod why would anyone want to code in Rust! It's a misconception worth spending 90 seconds in a video to correct.
Actually, not everything is allocated on the stack. String and Vector values are on the heap but the pointer to the value(s) is on the stack.
Thanks for the Rust code. I prefer Go for its simplicity. Below is a Go version of your program that walks the list and prints the values:
package main
import "fmt"
type listNode struct {
val int
next *listNode
}
func toList(vector []int) *listNode {
var cur *listNode
for i := len(vector) - 1; i >= 0; i-- {
newNode := &listNode{vector[i], cur}
cur = newNode
}
return cur
}
func main() {
var vector []int = []int{0, 2, 4, 6}
cur := toList(vector)
for cur != nil {
fmt.Println(cur.val)
cur = cur.next
}
}
Nice video. Can you zoom in a bit so we can watch this video on mobile? The font size is quite small.
This is such a nice explaination, one of the best I've see. I am coming from C/C++ so you saying things Box is just a smart-pointer make alot of sense to me :)
1:00 this has nothing to do with rust tho, its how structs work
More complicated than C++ when it comes to memory management. It’s the reality
how long have you been using rust?
I was learning as I made this series...so about 3 weeks before I made this video...I've been programming for about 10 years though
@@zwhitchcox what language did you pogram prior to this ? asking because of curiosity how is it is to transition from something like python vs c++
@@zwhitchcox Wow you did really well I've been using rust longer (not by much) but got tripped up trying to do the linked list and found your videos. Thanks I had trouble figuring out how to link all of them and follow the mutability rules.
awesome video👍
Very nice! Please do a double linked list! =D
Thanks mate!
Actually, linked lists in Rust are trivial -- you just use an already available implementation. They are only hard if, for some reason, you feel a need to re-invent the wheel. Perhaps you used them a lot in C, where you HAVE to implement them yourself by putting pointers in structs and keeping them up to date, and for some reason you would like to see what it's like to do the same thing in Rust. That's not something you NEED to do, or SHOULD do, or even would be PERMITTED to do when contributing to a real project -- it's just you screwing around, writing code you SHOULD DEFINITELY NOT USE, in order to recreate your C experience in Rust. The linked list code you really want to write is absolutely trivial, more trivial than in C -- you just use the API for the appropriate linked list implementation. And you don't have to test it; it has been separately tested, and it works.
By the way, linked lists were popular in the 80s, when microprocessors didn't typically have caches, but they are cache destroyers since entries are typically going to be in different cache lines. Arrays / Vecs / VecDeques are much more cache-friendly, and allocating/deallocating an entry is much cheaper, so they are often more performant even if you sometimes have to copy entries. And there are a lot of other data structures to choose from. So where performance (or memory) is a concern, a linked list might not actually be a good idea in the 21st century -- there is almost always a more performant way to get the same job done.
I think it's important to be clear about this, since people seem to get triggered about how how much they have to learn in order to reinvent linked lists in Rust -- something it would make no sense to do for anything real.
He's doing problem sets, one of which includes implementing a LinkedList. Not that deep.
its a exercise. I wont ever need to write a production version, sure. but doing it once makes sure I understand the rules properly.
By the way it is incorrect to say linked list cause cache misses. Just batch allocate the nodes.
Again, the point is that some people think that this means something terrible about Rust, because they re-implement linked lists over and over again in their C programs and naturally think that they'll need to do the same in Rust. They will NOT. I have no problem with doing this as an exercise, as long as it is accompanied by the clear explanation that this is not actually useful, not something anyone should do. If you DON'T explain that, then you just add to the erroneous impression that people need to write their own linked lists in Rust like they do in C, and goodness look how hard it is, so omigod why would anyone want to code in Rust! It's a misconception worth spending 90 seconds in a video to correct.
Rust is laughable