📝 Get your *FREE Rust cheat sheet* : www.letsgetrusty.com/cheatsheet
@ChumX1002 жыл бұрын
I really like how Rust doesn't hide complexity from developers behind trade-offs, but rather offers helpful tools to manage complexity as well as sensible defaults.
@HermanWillems2 жыл бұрын
This transparancy i like. I dislike magical garbage collectors and other stuff. This is why rust is so great.
@kevinmcfarlane27522 жыл бұрын
There are arguments for both, depending on your application domain. There is never a one size fits all.
@jay_browncomedy Жыл бұрын
biggest draw for me as well
@alinmgheorghe4 ай бұрын
Well put. I'm still wrangling my brain around some of the stuff but slowly it's getting there and with each step you realise how awesome it really is.
@thingsiplay3 жыл бұрын
I had trouble understanding the lifetime annotations system, until this video. The key information I needed was "It does not change the lifetime, but specifies relationships" explanation. Your videos and explanation are clear and easy to follow. Can't wait to see more material. Thanks for going through this and doing all the work.
@letsgetrusty3 жыл бұрын
My pleasure!
@piranhi2 жыл бұрын
Came here to say exactly the same thing
@NathanHedglin Жыл бұрын
Dido
@TheOracleFile2 ай бұрын
@@NathanHedglin Definitely this in combination with the fact that the borrow checker now uses the passed params to compare the lifetime with result
@egonzalez42942 ай бұрын
Funny how people understand things differently, for me that was meaningless, what made sense to me was like, "the compiler needs to know the lifetime of the output" I thought what would it be like to be the borrow checker, and try to figure out the code. These annotations just help the checker figure things out.
3 жыл бұрын
Frustrated beginner Rust programmer: "Just let me write bad code!!" The Rust compiler: No. Here's some super helpful tips instead.
@joelimbergamo6393 жыл бұрын
That's exactly how I feel writing rust, I want to write code that I know it's wrong but I want to only try it and rust forces me to write good code, it's a love hate relationship 😂
@garlicat8782 жыл бұрын
Exactly. We should make a meme like: Me after learning other languages for hours: Wow Let's make a app/game/website. Me after learning Rust for weeks: Why doesn't it compile? What lifetime annotation should I put here? Should I borrow that thing?
@HermanWillems2 жыл бұрын
I love Rust is forcing me to do the right thing. For example it forces me to handle the options, use the match. But also with using the match statement it forces me to use all posibilities. No null. I love it doesn't have null. (Well in safe space though) but i like how its the default. The defaults are chosen perfectly.
@vorrnth87342 жыл бұрын
@@joelimbergamo639 Having had to debug muuuch bad code I really love this behaviour. Dangling pointers can be a real pita.
@conradmbugua90982 жыл бұрын
🤣🤣🔥
@Hardzinho_Yay Жыл бұрын
As a Java/Node/python programmer and learning Rust I never understood lifetimes in Rust, you`re the first to make this `click` in my brain. Thank you.
@richasha6703 жыл бұрын
I totally understand lifetime by your video! Thank you so much as a Rust beginner, you made me understand Rust Book 200%!
@kevinmcfarlane27522 жыл бұрын
Yeah he complements the book nicely. I find with technical topics that I need a combination of written material, presentations like this and experimentation/practice to get the richest understanding.
@AlanDarkworld2 жыл бұрын
Whoever decided to use single quotes in a non-pairwise fashion in the Rust syntax just wants to see the world burn.
@Lexikon003 жыл бұрын
I just wanted to address something that a lot of new rust programmers get wrong, and you also did explain it wrongly. At least it's rarely the case someone wants to do this. I'm going to copy the code you used for the illustration: struct ImportantExcerpt ImportantExcerpt
@letsgetrusty3 жыл бұрын
Hey Alexander, thank you for the correction and taking the time to write this out.
@johnegan24842 жыл бұрын
To clarify, because there are two input lifetimes both &self and announcement:&str are given their own lifetimes.(Rule #1) Because one of the parameters is &self, the return type gets the lifetime of &self. (Rule #3)
@bertolucci19853 жыл бұрын
Thanks for taking the time to produce these videos mate. Learning Rust concepts alone isn’t easy. I appreciate it.
@chsblue23 жыл бұрын
Perfect explanation. You just gave me that little extra information that I was missing to finally get it into my head. Thx man! 👏🏻
@kumatmebrah9044 Жыл бұрын
Watching this after going through the chapter helps drive the point home. I'm glad I found this.
@GolangDojo3 жыл бұрын
Just let me live life dangerously
@ajesh-mishra3 жыл бұрын
Rust Compiler: Nope! Not on my watch ⌚ safety first 🎈
@vorrnth87342 жыл бұрын
Then do C or assembler.
@embedded_software Жыл бұрын
I was watching this video on the treadmill, and I was enjoying it so much that I actually worked out longer than I was planning without even realizing it until the video was over! Thanks, Bogdan!
@dmitriidemenev52582 жыл бұрын
Hi, Bogdan! I would be really cool to see a video about structs where some fields reference others. More precisely, why it is or is not bad and what are the alternatives.
@zemja Жыл бұрын
You cannot do this in Rust.
@joehsiao6224 Жыл бұрын
Resolving a longtime mystery in my mind feels so good. I'd spam the like button if I could.
@johnegan24842 жыл бұрын
You state at ~13:15 that the lifetime annotation is saying our struct cannot outlive the reference passed into part:first sentence so if we try to use our variable i (agreed) which is an instance of our struct after part:first sentence has gone out of scope we would get an error. However, would note that the annotation means that an instance of ImportantExcerpt cannot outlive the reference it holds in its part:first_sentence field and in that regard the reference in the ImportantExcerpt instance is valid, the owning variable novel does not go out of scope prior to ImportantExcerpt going out of scope.
@sahilverma40773 жыл бұрын
Damn, we have a lot of restrictions, but I wish if I get through all these problems I will have a safer, low level, and fast code. Btw, I recently saw in google news that google is rewriting some part of android with Rust, wish more companies start adopting it.
@letsgetrusty3 жыл бұрын
It's good to catch the wave early :)
@ajesh-mishra3 жыл бұрын
Also the new modules in Linux Kernel may be written in Rust and that would be big!
@darshanv17482 жыл бұрын
at 16:50 if we return announcement from the function , then according to lifetime ellisions it'll be assigned lifetime of self, but don't you think that it might be wrong in some cases
@proloycodes2 жыл бұрын
yes it will be wrong. im sure it will give some "announcement does not live long enough." type of error
@klaymen02 жыл бұрын
Thanks for the video series, it's a great addition to the book as it gives a different perspective to a lot of things. One thing I wonder about lifetimes (and I'm learning, so maybe I did not grasp the concept fully yet): It seems to me that assigning the same lifetime 'a to ALL parameters of a function plus all returned parameters is the most restrictive way possible in terms of lifetimes. If an actual use of a function fulfills these "strictest" rule, why is it actually required to write these lifetimes out when defining it? I think, in the longest-string example, no different lifetime declaration than this most restrictive one is even possible - if you try it, a bug occurs where you try to return the "other" parameter. I understand it's probably a complex problem for the compiler, maybe NP-complete, to find the optimal setting, but in cases where the most restrictive remaining one works, why not defaulting to this? One possible explanation (and maybe this is the reason) is when you write a library that exports functions, so the compiler does not know how it is actually used, so lifetime declarations must be exported as well. But this would not apply for private functions. Another way to make it easier would be to add a mode (maybe compiler flag) to automatically fill up lacking lifetimes with the most restrictive setting still possible? Or what also might be interesting (maybe this exists) were external tools, a bit like lint, or optimally included in an IDE, that could auto-suggest lifetimes?
@fixpoint3 жыл бұрын
Thank you for explaining lifetimes in a clear and easy to understand manner. I just discovered your series and can’t wait to go through the rest of them! Thank you for the time and effort you have put in to produce these.
@sulfurasmr6365 Жыл бұрын
this channel has been hugely helpful for me trying to learn rust, especially since I've never heard of a language doing 'borrowing' before. thank you so much!
@oliverhunter18472 жыл бұрын
Hands down, the best explanation of lifetimes I've ever seen
@web3987 Жыл бұрын
Thank you for such a comprehensive lifetimes lesson. The learnings from this video will last a lifetime.
@gzoechi Жыл бұрын
Good explanation of a bunch of things I had a really hard time understanding from the Rust book, when I started learning Rust. This could have spared me a lot of pain 😬
@abhinavchavali14433 жыл бұрын
This is the best youtube video I have ever watched.
@oyunovacom2 жыл бұрын
Bogdan, this video is even clear for me as a code illiterate! Thank you for this and PLEASEEEE keep your lectures this minimal! Cheers!
@SansDev7 ай бұрын
This series is outstanding tbh, thank you for your hard work. Understanding each of Rust's features makes me love it so much more!
@2002budokan2 жыл бұрын
You know what? This is currently the best video resource to learn Rust. Thank you Bogdan.
@tobi96488 ай бұрын
wow, I saw these 'a-ticks and couldnt find a good/easy explanation for it. You just explained it so easy and perfect. Thanks!!
@RoamingAdhocrat Жыл бұрын
and you may ask yourself, why did I struggle with this? Thanks for the explanation. I'd found lifetimes confusing up to now, but the way you demonstrated it, it's quite straightforward!
@LagDaemonProgramming2 жыл бұрын
Your explanations of these topics are concise, complete, detailed and you move right along with them. Outstanding job, all of your videos make these ideas very clear. I tip my hat to you sir! :)
@gitgudsec5 ай бұрын
your videos are just so incredible man, extremely grateful for these beautifully articulated insights you put out
@Tanger68 Жыл бұрын
You explain this very succinctly, thank you very much! In my mind, lifetimes are almost intuitive once you think about it. I think I just double guess myself because I expect it to be more complex than it is!
@mmmbug6 ай бұрын
You're a great teacher. Thank you for making this video! Do you know why lifetimes in Rust are rarely given descriptive names? Almost every example I find uses single-letter names like "a".
@TAT4guitar Жыл бұрын
I have been learning Rust from youtube and Rust by Example, and your videos always do the best job when it comes to tricky concepts such as ownership and lifestime. Thanks a lot!
@meka49963 жыл бұрын
Your explanation is super clear! I know lifetime now! Thank you
@oussamasethoum2755 Жыл бұрын
If the block doesn't end until line 230 but the variable is not used after line 100, does rust deallocate the variable in line 101 or until the block ends? what is the case for the garbage collector?
@absarrahman91779 ай бұрын
THIS IS BY FAR THE BEST EXPLANATION. Keep it up man
@b_mathemagical8 ай бұрын
I rarely comment on videos, but you did a great job with this. Thanks for sharing!
@twentyeightO12 жыл бұрын
This channel is a blessing!
@dimiutube9 ай бұрын
Awesome! Good explanation of the lifetime concept. I'm looking forward to deal with different lifetimes for variables and convince the compiler that all I'm doing is well planned 🙈 Thank you very much!!
@user-dg9cr6wu9i3 жыл бұрын
Awesome! These examples are very clear for rust lifetime.
@strawz19882 жыл бұрын
Thanks for such a neat explanation. Just a request the audio is little low
@vijaysinghbisht30162 жыл бұрын
Why so less comments? This channel deserves far more attention than this... Sadness
@hhhuhhh56929 ай бұрын
Thank you so much! This video and the others in this playlist really helps me understand Rust better! ❤
@kch90015 ай бұрын
Best lifetime explanation on youtube
@filipslezak51523 жыл бұрын
I don't know why but rust is giving me some feeling of completion when binary is complete and running as expected.
@PremalUpadhyay2 ай бұрын
Hi, can you make series on poem framework of rust? Lack of resource availability is major concern and first obstacle to get started with it. Thanks :)
@sebastianospino4861 Жыл бұрын
That is, the lifetimes only inform the compiler of the lifetimes that these references must have, and it checks if these conditions are fulfilled in the code, and if not, an error is raised.
@Mortesins Жыл бұрын
Thanks for the comment, it was exactly what I was missing.
@michaelkastner3611 Жыл бұрын
Again, another great episode.
@MameMedouneDiopXpert Жыл бұрын
Lifetimes are clear now! Thank's a lot Bogdan
@jayleejw1801Ай бұрын
My first time learning about lifetime in rust. I didn’t think it’s that difficult. In fact, it’s common sense. It’s about preventing dangling reference, meaning a reference to something that doesn’t exist anymore, which is a memory issue. Explicitly writing the tick generic lifetime annotation actually makes programmer think smarter about avoiding referencing something that may not live long enough in the program. It’s all about lifetime and it’s really that simple. Anything to do with reference, be careful with its lifetime, because you might reference to invalid memory. And some rules to follow, if only one reference parameter, there’s no need to write the lifetime annotation because definitely your output reference depends on it. If more than one, then you have to write the annotation and borrow checker will be able to determine, such that output reference lifetime is the smallest of the two parameters lifetime. Simple.
@kevincarvalhodejesus44732 ай бұрын
Very well explained, thank you!
@CountJamesMcGuigan2 жыл бұрын
Thank you for your tutorial. As a small piece of feedback for future videos, the faint music in the background was slightly distracting.
@meowsqueak Жыл бұрын
It seems to be a trend in programming videos lately, and it is VERY distracting. I often find myself pausing the video thinking it’s from elsewhere in my house. I really wish these otherwise talented content creators would ditch the pointless and distracting background audio - it almost ruins what would otherwise be an excellent resource.
@OggerFN2 жыл бұрын
Great video. Only thing I miss here would be showing how different lifetimes interact with each other inside the fn scope to further illustrate the concept.
@NeotenicApe3 жыл бұрын
Your videos are amazing! Thank you so much ❤️
@PoetNoPoems3 жыл бұрын
These videos have been fantastic, thank you
@fhdiaz872 жыл бұрын
It would had been useful to mention that life time could be coerced. That is a reason to use just a' when actually both parameters have different life times.
@andriesvanwyk32263 жыл бұрын
Very clear explanation! Thank you!
@chlbri Жыл бұрын
You explain very well some difficult notions.
@marinhobrandao6 ай бұрын
I loved to know you like The Wheel of Time as well :D
@sakuranooka2 жыл бұрын
Ok, I understand half of this. What I don't understand is e.g. why I need to add /'a/ so many times. Why for instance do we have to add it in angle brackets after the function name? The simple answer to this would be "because Rust requires it", but I'm interested in the longer answer to "why does Rust require it? Is there anything that wouldn't work if in a language Rust2.0 only the input and output arguments had lifetime annotations, but not the function itself?". What I don't understand either is why x and y have the same lifetime annotation, even though we just said x and y can have different lifetimes. And could you show an example where we need more than one lifetime specification, e.g. /'a/ and /'b/? Thanks for these otherwise extremely helpful videos :)
@healthytips48182 жыл бұрын
hopefully someday rust just use AI to generate this lifetime annotation :D
@swapode2 жыл бұрын
x and y have the same lifetime annotation because the return value's lifetime depends on both of them. It doesn't matter that x and y can have different lifetimes, it's important that the values of both x and y outlive the return value, since the return value can be a pointer to either one. I made a simple modification to the longest() function, to demonstrate how two different lifetimes might be useful: fn weird_longest(x:&'a str, y:&'b str) -> Result { if x.len() > y.len() { Ok(x) } else { Err(y) } } While this also would compile with a single lifetime, it'd mean different things on the call side. Two different lifetimes would allow us to discard one of the actual values, while with the same lifetime we'd have to keep both of them around until the return value goes out of scope. I'm actually not quite sure about "why does Rust require it?". I can't come up with a counter example on the spot, something to think about. One reason might be something like monomorphization, explicitly declaring the lifetimes makes it clear that this is a generic function that might be compiled several times for different calls (what if both parameters have static lifetime?) but I can't quite wrap my head around it.
@pynchia41192 жыл бұрын
can you please explain the syntax on line 5 @7.30 ? Don't types follow the colon? Are you assigning a value to the arguments of the call to longest? If so, why isn't an equal symbol used? Are you casting their type instead? And what is the need of using .as_str() in the first place?
@aidenlilley13192 жыл бұрын
I don't understand the first part of the question but the point of calling .as_str() is to get the reference, as this video is about reference lifetimes.
@Gramini Жыл бұрын
Do you mean the "x: string1.as_str()"? The pattern "var: type = value" only applies to creating variables. The things inside longest(…) are not variables, but passing parameters. When calling functions you can use named parameters, meaning the parameters are not passed in the order they are defined in but by the names they are defined as. To do so you specify the parameter name, a colon and then the value. "x: string1" means "For the parameter named x use the value string1". These grey, smaller text is generated by the IDE/code editor as hints and are not actually there.
@stanislavstudzinskyi23472 жыл бұрын
Outstanding quality. Thank you so much for your labor!
@dulanjala2 жыл бұрын
this is a nice little tutorial with so much value. Thanks!
@gaelanm39202 жыл бұрын
Let's start out by talking about ding-a-ling references. In all seriousness, great video.
@LimitedWard2 жыл бұрын
This was really helpful. So far this seems to be the "ugliest" part of Rust's syntax, though, I guess it's just a direct consequence of having a borrow checker. What's the general consensus on the use of lifetime annotations? Should we be writing code to explicitly avoid needing them whenever possible?
@Daxlo2 жыл бұрын
I'd love it if someone who knows could answer this question! I think they become important when you have references in multiple data structures. For example, two Vectors contain a reference to the same value.
@kevinmcfarlane27522 жыл бұрын
What tends to happen with languages is that they simplify the syntax over time. Though in the meantime they add more concepts with more syntax. Lol.
@thebsv6 ай бұрын
Have a small question about the last example, what is the lifetime of the variable ann which has a generic type T? Why wasn't it explicitly mentioned, like the other input parameters? Would 'ann' also have the same lifetime as x and y, meaning 'a?
@AndresFH72332 жыл бұрын
Dude great explanation, I finally got the concept!
@lee452833 жыл бұрын
Great video, thanks for the content!
@walter0331 Жыл бұрын
I spent an afternoon trying to figure out how lifetimes works, finally understood after watching this vid 🤦🏻♂️
@murugarajuperumalla55082 жыл бұрын
Super, this video is enough to understand lifetime, thanks a lot ❤️❤️
@kiddkai2 жыл бұрын
Great video, help me understand the lifetime annotation!
@Timjstewart11 ай бұрын
So thorough and interesting! Thanks!
@jacques-dev2 жыл бұрын
Wowie. Thanks Bogdan!
@vijaysinghbisht30162 жыл бұрын
Thank you very much.. Explained very nicely.. Can you do a day event?
@gauravpoudel72882 жыл бұрын
AWESOME EXPLANATION.!! thANKS SO MUCH!
@tourdesource2 жыл бұрын
Clear as day. Thank you!
@rahatsshowcase86144 ай бұрын
You explained really well! and after your explanation I was like is there any single case even where i will need 2 lifetime annotations like 'a and 'b to express my logic! because i think i could do my lifetime annotations for any function or struct just by using 'a only! because if u look deeply for functions it's just annotating all your parameters with 'a which have the possible to be returned from your function and return 'a on the other hand for struct as the struct will become invalid if a single property containing a ref becomes invalid which means we can always pass a single lifetime through the whole struct? because i have tried 5-10 examples and all are working with a single annotation perfectly as expected! so let me know your opinion regarding this!
@madhank933 жыл бұрын
Very nicely done. Thank you 🙏
@user-ko5yr9mo6d3 жыл бұрын
намного понятнее чем в книжках. Спасибо)
@Scramblejams11 ай бұрын
I believe this could use an update now that the non-lexical lifetime analyzer has been updated, correct? For example, I do not get an error with rust 1.72.1 on the code sample at 13:00.
@hungnguyenthanh2800 Жыл бұрын
Very nice explanination!!!!
@abraham79662 жыл бұрын
This is sooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo helpful. I am reading the Rust book at the moment and I am about to learn lifetimes but this gives me such an amazing foundation!!!! Thanks for explaining this concept! It is great to have people that cares about explaining confusing and hard topics rather than the same easy subjects.
@berliangigihprakoso69483 жыл бұрын
very good man, your videos is easy for beginer like me.❤👍
@aaronzolotor430 Жыл бұрын
This was amazingly helpful!
@kvasco-iu8nq2 жыл бұрын
Superb! really good explanation, got some small pieces that help me to get my head around this lifetime thingy. in the fn longest example, m 11:02 it works if we use string slices instead of Strings, my guess is because these implement the copy trait ? hence the values are moved so the reference to result is valid at the end ?
@shhhhhhKoiHai3 жыл бұрын
This is great explanation. Love it. Thanks.
@NoNameEntered2 жыл бұрын
Great video and examples! Thank you!
@mr.bulldops76922 жыл бұрын
Lifetimes being relational is a revelation.
@jamesbarrow Жыл бұрын
Smashed the like button. Didn't smash subscribe, already done that before ;)
@rjlacanlaled941910 ай бұрын
Does this still apply, or are compilers more advanced now that we don't need to use generic lifetime annotations anymore?
@funkdefied19 ай бұрын
Thank you!
@Jordan4Ibanez2 жыл бұрын
I wish I could like this video more than once
@pygeekrfoo82011 ай бұрын
Chap 10 is a kick to the nuts.
@dadestor Жыл бұрын
Great video and explanation, thanks
@zombieshoe2 жыл бұрын
Hi! This might sound silly but I was just wondering why the Rust compiler can't automatically assign the lifetime based on which values are returned. For example, in the "longest" function, why can't it return a reference to x with the same lifetime as the input reference to x OR a reference to y with the same input lifetime as the reference to y?
@alagaika8515 Жыл бұрын
Because this question can not in general be answered at compile time.
@zombieshoe Жыл бұрын
@@alagaika8515 But my question was why. When I think about it in my head, I could imagine a way of determining how to configure a compiler to do what I suggested. Maybe you could give an example of where there'd be ambiguity?
@alagaika8515 Жыл бұрын
@@zombieshoe I think the problem is that a lifetime is not some information that is stored together with the value of the variable. It is a compiler restriction on what functions can be defined. If you defined the largest function without explicit lifetime hints and used the last example where one string is defined in the outer scope together with the result reference and another in the inner scope, but the values of those strings are only determined at runtime by user input - how should the compiler determine if the code results in some access to a freed memory address or is valid?
@zombieshoe Жыл бұрын
@@alagaika8515 I think you and I would both agree that the value of the string shouldn't matter and that instead what is important is if it's None or Some. It's been quite some time since I watched the video so I may have to refer back to the last example, but it seems to me that a user defined string is no different than a precompiled one in the sense that that only difference is the location of the pointer and NOT the lifetime of the variable. And so yeah I'd assume returning the string that has the outer definition would outlive that of the inner definition. Again, I could totally be missing something, so I'm sorry if I sound silly lol
@alagaika8515 Жыл бұрын
@@zombieshoeThe value of the string determines which one is longer (has more characters) and therefore if the function returns a reference to x or to y. One of these will be freed before the other, so in order to ensure that there never remains a reference that is no longer valid, the compiler can only ensure that the result will be valid at least as long as the shortest lived input. This could probably also be a fallback rule to use if no explicit lifetime annotations are given, not sure what reasons the rust designers had for this decision.
@unduloid10 ай бұрын
So when would you use mixed lifetimes?
@bob553205 ай бұрын
The video is great and I really appreciate the explanation. However, the background music is quite annoying, even if it is very low volume. I kept wondering if someone was playing music in the other room. I would personally prefer that there was no background music at all. Hopefully you find this feedback constructive and please understand that I am writing it with the best of intentions! Thanks!
@kg32172 жыл бұрын
Thank you : ) Thanks again Thanks a lot Thank you for explaining it so well 🙏