ฝัง
- เผยแพร่เมื่อ 5 ธ.ค. 2023
- Let's figure out Rust's lifetime concept. We'll walk through a small Rust program that uses references and see what Rust means when it talks about a lifetime (and why Rust is so loud when it detects an error).
Please support Tim through Patreon! / timclicks
The speaker further explains Rust’s warnings against reusing references and introduces terms such as 'Box' and the creation of values outside the function's local scope. The video successfully simplifies complex ideas like data allocation, reference modification, and the static lifetime concept.
I hope that this is a useful resource for all developers wanting to deepen their understanding of Rust programming language. Suggestions for future videos are very welcome!
🦀 Rust resources:
- Tim's tutorial videos timclicks.dev
- Rust Documentation: doc.rust-lang.org/book/
- Rust Playground: play.rust-lang.org/
- Rust in Action (Tim's book!) mng.bz/4MlD
- How to Learn Rust (online course!) learning.accelerant.dev/how-t...
👋 Connect with Tim:
- Twitter: / timclicks
- GitHub: github.com/timClicks
- Mastodon: mastodon.nz/@timClicks
- DEV: dev.to/timclicks/
- Patreon (extra learning materials) / timclicks
🔔 Subscribe to the channel and click the bell icon to stay updated with the latest videos and live streams from timClicks: th-cam.com/users/timClicks?sub...
👍 Like this video if you found it helpful, and share it with your friends who are also interested in Rust programming. - วิทยาศาสตร์และเทคโนโลยี
I have the most problems with lifetimes when assigning lifetimes to structs. Whenever a struct holds a reference to something it needs a lifetime spec. Then a cascade of items need a lifetime and it gets quite messy. I just avoid references in structs.
Explaining it in C/C++: In a function, when you have a pointer to a local variable, don't ever let some object you got from outside keep it, and don't ever return it, because after the function ends that variable dies and now your pointer points at nothing.
Always use a pointer to a heap allocated variable for that.
C and C++ won't bat an eye if you do that, the C and C++ compilers don't give a shit about it. But Rust won't.
I wrote the code, it works, but I don't understand how it works. that's what lifetimes are to me.
The first video I see about rust lifetimes without practical examples of lifetime annotations 😆
Very good. Thank you
nice video. keep up the great work. quick question: what's the VSCode theme/color palette and font that you were using in the previous video? it's been haunting me :)))
Sorry for not responding sooner! It's actually custom. I am still working on it and hope to publish it as a theme at some stage
@@timClicks figured as much :) thanks a mill. have a good one
4:30 when should I return something via Box, and when should I choose the static lifetime instead?
Return a Box, unless the circumstances require something else. That's very rare. I added the leak in this example because it introduces the static lifetime.
Why Mutex needs to be enclosed behind Arc? Why not just Rc?
Well I understood it as I wrote the question. It's because mutating the reference count is not safe, even though mutating the Mutex is safe.
So I believe it is safe to conclude that values inside Arc are generally not thread safe, to support Write.
So the values insde Arc should be immutable?
Will be better if you can illuminate on this topic.
The two wrapper types need to work together. Shared access does not imply shared ownership, nor does shared ownership imply shared access.
Ownership in Rust primarily relates to the responsibility to clean up data. It does not relate to something akin to property rights that allow the owner to exclude others.
*a_ref (100) + 900 => b (900)
Am I getting something wrong?
you may learn Rusty's lifetimes in a lifetime
I don't think that doing "Box::leak(Box::new(b))" is a good approach...
why not though