Rust's lifetimes made easy

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....
- Rust Playground: play.rust-lang...
- Rust in Action (Tim's book!) mng.bz/4MlD
- How to Learn Rust (online course!) learning.accel...
👋 Connect with Tim:
- Twitter: / timclicks
- GitHub: github.com/tim...
- Mastodon: mastodon.nz/@t...
- 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: www.youtube.co...
👍 Like this video if you found it helpful, and share it with your friends who are also interested in Rust programming.

[@chuckcarlson7940]

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.

[@yoavmor9002]

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.

[@theoutsider01]

I wrote the code, it works, but I don't understand how it works. that's what lifetimes are to me.

[@wongyikfoong]

👍👍👍👏👏👏😂😂😂🙉🙈

[@antoniong4380]

See it as this, you yourself already do lifetime ellision to your code. Just not perfect, and might even be gaps in your understanding, but nevertheless you still subconsciously do lifetimes ellision as long as you work with languages that don't rely on GC. (C, C++ being the common non GC languages)
So the compiler doing lifetimes checking for you, just means that you yourself wouldn't strictly be worried abouy lifetimes, almost as close as how you don't worry about "dangling pointers" in languages like Java.
There are some edge cases like holding a reference in a match block due to how the code desugars, but this is minor. A the only caveat is that you should try your best to not do lifetimes to pointer of pointer, because otherwise it becomes a mess.

[@theoutsider01]

@@antoniong4380 thanks! that's a new way of looking at it for me. I'm mostly having trouble because I've only seriously worked with GC languages. I'm just throwing myself against the wall (with pet projects) to bruteforce this "intuition".

[@DanielSantanaBjj]

The first video I see about rust lifetimes without practical examples of lifetime annotations 😆

[@p4luagecehmg810]

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 :)))

[@timClicks]

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

[@p4luagecehmg810]

@@timClicks figured as much :) thanks a mill. have a good one

[@GL1zdA]

4:30 when should I return something via Box, and when should I choose the static lifetime instead?

[@timClicks]

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.

[@goodnewsjohn2482]

Drawing the stack out is a good visualization technique

[@meka4996]

Very good. Thank you

[@TheDelcin]

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.

[@timClicks]

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.

[@jorgealfonso1600]

you may learn Rusty's lifetimes in a lifetime

[@abdelhakimkhabir]

I think that no video is near to the brown university book explanation. It's hard way of learning. But it's also nice to do some variation in the learning style.

[@TarasShabatin]

*a_ref (100) + 900 => b (900)
Am I getting something wrong?

[@methylphosphonofluoridate]

I don't think that doing "Box::leak(Box::new(b))" is a good approach...

[@simo_the_goat]

why not though