Rust's lifetimes made easy

[@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.

[@goodnewsjohn2482]

Drawing the stack out is a good visualization technique

[@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".

[@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.

[@DanielSantanaBjj]

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

[@anthonyjaccard3694]

Yeah, it's basically a video about scope, not lifetime. The concepts are linked but when you come from any other language, scope isn't the part you have problem with in rust, lifetime and especially lifetime annotations are

[@Heater-v1.0.0]

Well, lifetimes are a thing even without lifetime annotations. Lifetimes are a major thing to be aware of when using C, C++ and other such. compiled languages even though those languages have syntax or semantics to represent lifetimes. Lifetime are a property of data items.

[@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

[@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.

[@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.

[@meka4996]

Very good. Thank you

[@jorgealfonso1600]

you may learn Rusty's lifetimes in a lifetime

[@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

[@methylphosphonofluoridate]

@@simo_the_goat From Black Hat Rust: "In my opinion, lifetimes annotations should never surface in any public API. It’s okay to use them if you need absolute performance AND minimal resources usage AND are doing embedded development, but you should keep them hidden in your code, and they should never surface in the public API." - Sylvain Kerkour

[@beaticulous]

Learning Rust is so eye opening. Most other languages hide the truely ugly reality of writing programs for computers. They feel like childrens toys after Rust.

[@anthonyjaccard3694]

If you compare to python, javascript, java/C# I get why you would think that but if you've ever programmed in C/C++, you are very much aware of everything that's needed to write computer programs. You also understand why memory safety is important but I've never felt more like a child than after picking up rust. So many of its features are meant to protect you from writing unsafe code but it's done in such a way that you constantly feel restricted or overburdened. So many data structures rely on references but in rust, if you want to implement them you either have to deal with complex lifetime or complex smart pointers. I feel like if you are smart enough to understand rust's lifetimes, you are smart enough to write memory safe code in C/C++

[@internethistory6957]

this is the worst explanation i have ever seen