The other day I thought, "creating a linked list type will be a nice exercise as a Rust beginner". Didn't take too long to realize it wasn't going to be nearly as obvious as I expected XD
5 minutes in and I love this video already. The folks who can attend classes in this university and with this teacher are really lucky. Good luck to y'all. Thanks for the great video.
Java doesn't run into the problem of infinite recursion, bc. in the class body, the "List next" ist implicitly a reference (or "pointer"), so not a full definition, so there's no recursion actually. In Rust, the pointer/reference must be made explicit. Haskell avoids the same recursion problem by "Lazy Evaluation". When it sees the same type within a type definition, it says: "as long as there's no actualy evaluation, but only a type declaration, I don't need to follow that recursion".
Thanks for these videos, Sami. The comparison with Java around 5:30 might have been clearer -- and fairer -- if the Java version also used generics. Realistically you wouldn't make a Node contain a reference to Object in Java. Showing side-by-side *generic* code in Java and Rust would allow you to focus on the *relevant* differences between the two languages.
Thank you for the feedback and definitely something I will fix for next semester! I wasn't sure if the students knew about Java generics or not when I used the example but I suppose if I'm already using it in the Rust example it only makes sense to have them both that way.
This was said at 10:20 The comparison is Rust's Ownership model vs. C++'s raw pointers/ability to leak memory (this along with Concurrency is what Rust is famous for, which is why you'll see this comparison very often in Rust material), not Rust Ownership vs. C++ smart pointers.
Technically we can't do multiple owners in safe Rust. Technically, we can only do it using the standard library or implementing the feature itself using unsafe. But, again technically, multiple ownership is impossible using only safe Rust.
I love what's going on here. Very useful. But is it possible to silence the terrible music and sound effects during the quizzes. Sounds like some horrible TV quiz show.
Isn't just one & mut violating the "one writer rule"? let s = string::new() ; let s1 = & mut s; s.push_str("writer1"); s1.push_str("writer2"); So we already have the problem. In my opinion the one writer rule is dumb. Having multiple mutable and immutable refrencees at the same time is often needed and no problem when it comes to memory safety. Since we would still have 1 owner. Many languages work perfectly fine with this. For example in java you could consider every object refrence to be a &mut. Even the simplest of data structure in rust (vec) needs to violate this idiom to exist. The iter_mut() on vec uses unsafe rust because it is impossible to do without it.
@PeepNSheep but 2 mutable references wouldn't do anything in terms of memory safety. The owner of the value is still clear. Even if 2 mutable references exist they still can't outlive the owner. Where is the difference between mutable and non mutable references? Sure one can modify the variable but that doesn't effect memory management.
@PeepNSheep thats thread safety and not memory safety in aspect of memory leaks and segfaults. It's a completely different topic. And forcing thread safety onto potential single threaded operations or even programs is bothersome and potentially slower. Java for example gives no guarantees for thread safety if you don't explicitly use some sort of mutex. This removes the burden of mutation correctness from single threaded operations.
The other day I thought, "creating a linked list type will be a nice exercise as a Rust beginner". Didn't take too long to realize it wasn't going to be nearly as obvious as I expected XD
5 minutes in and I love this video already. The folks who can attend classes in this university and with this teacher are really lucky. Good luck to y'all. Thanks for the great video.
Finally I really understand what a box is. I don't get why nobody said to me, a box is a smart pointer. So simple
Java doesn't run into the problem of infinite recursion, bc. in the class body, the "List next" ist implicitly a reference (or "pointer"), so not a full definition, so there's no recursion actually. In Rust, the pointer/reference must be made explicit. Haskell avoids the same recursion problem by "Lazy Evaluation". When it sees the same type within a type definition, it says: "as long as there's no actualy evaluation, but only a type declaration, I don't need to follow that recursion".
this was wonderful, thank you :)
I’m 17 years old and I know Java completely and started learning rust like 4 days ago your lectures are very good thank you!
Thanks for these videos, Sami.
The comparison with Java around 5:30 might have been clearer -- and fairer -- if the Java version also used generics. Realistically you wouldn't make a Node contain a reference to Object in Java. Showing side-by-side *generic* code in Java and Rust would allow you to focus on the *relevant* differences between the two languages.
Thank you for the feedback and definitely something I will fix for next semester! I wasn't sure if the students knew about Java generics or not when I used the example but I suppose if I'm already using it in the Rust example it only makes sense to have them both that way.
Thanks Sami. Your way of teaching a amazing. RUST
Great course content - thanks!
In the single linked example, the head node will not point to the next node, but a copy of the next node on the heap!
In terms of your face square covering the text, you could play with the transparency of your square so that, even when you cover text, it can be seen.
Also, thank you for the video!!!
Rc is the TV remote controller - easy to remember
C++ has smart pointers too! You wouldn't need to automatically clear memories. It's C that doesn't have any in the stdlib.
This was said at 10:20
The comparison is Rust's Ownership model vs. C++'s raw pointers/ability to leak memory (this along with Concurrency is what Rust is famous for, which is why you'll see this comparison very often in Rust material), not Rust Ownership vs. C++ smart pointers.
Technically we can't do multiple owners in safe Rust. Technically, we can only do it using the standard library or implementing the feature itself using unsafe. But, again technically, multiple ownership is impossible using only safe Rust.
“Memory blocks touching each other“ didn’t watch any further
My school is teaching racket 😭😭😭
I love what's going on here. Very useful. But is it possible to silence the terrible music and sound effects during the quizzes. Sounds like some horrible TV quiz show.
Perhaps we could lower the volume on it a bit 🤔
Isn't just one & mut violating the "one writer rule"?
let s = string::new() ;
let s1 = & mut s;
s.push_str("writer1");
s1.push_str("writer2");
So we already have the problem. In my opinion the one writer rule is dumb. Having multiple mutable and immutable refrencees at the same time is often needed and no problem when it comes to memory safety. Since we would still have 1 owner. Many languages work perfectly fine with this. For example in java you could consider every object refrence to be a &mut. Even the simplest of data structure in rust (vec) needs to violate this idiom to exist. The iter_mut() on vec uses unsafe rust because it is impossible to do without it.
@PeepNSheep but 2 mutable references wouldn't do anything in terms of memory safety. The owner of the value is still clear. Even if 2 mutable references exist they still can't outlive the owner. Where is the difference between mutable and non mutable references? Sure one can modify the variable but that doesn't effect memory management.
@PeepNSheep thats thread safety and not memory safety in aspect of memory leaks and segfaults. It's a completely different topic. And forcing thread safety onto potential single threaded operations or even programs is bothersome and potentially slower. Java for example gives no guarantees for thread safety if you don't explicitly use some sort of mutex. This removes the burden of mutation correctness from single threaded operations.