ERRATA * I mention that you get a segfault when you don't deallocate memory in C/C++ - I meant to say that you get a segfault when you try to reference memory that was already deallocated. Not deallocating memory will lead to memory leaks in some cases.
It's not generally true that accessing deallocated memory causes a segfault either. Actually, it would be more helpful if that was the case, since it would be easier to debug than the case where your program is silently accessing data that may or may not be garbage depending on the execution state.
ugh, you're absolutely right! This was an egregious mistake. Not deallocating will result in a memory leak. I meant to refer to the case where we erroneously deallocate memory and then try to reference that memory. I'll put a note in the description, thanks for pointing this out!
@@codetothemoon Also, you can segfault if you correctly deallocate memory and then (because you had more than one reference) you deallocate it again and corrupt the malloc recordkeeping. Sometimes this takes quite a while to blow up on you!
I like what you are doing here. I am glad that No Boilerplate is influencing people because I am sick of all the stupid presentations in other channels. 1 minute of BS, songs, animations, and people presenting their channels and welcoming as if we were 6 years old watching Ryan's toys reviews.
Thanks! re: the filler stuff - yeah I'm not a fan of lengthy introductions either. I'm not entirely above obnoxious animations (see earlier videos) but I definitely like to get to the point 😎
7:44 In case anyone is wondering why the mutable reference will work if you remove the last `print_some_struct` which uses an immutable reference. This is because of NLL (non-lexical lifetimes). In short, the compiler infers that it is able to drop the immutable reference borrow before it gets to the mutable reference, because it's not used anywhere later. Thus, you only have one mutable reference, which doesn't break any rules
Great, as if Rust hadn't gone out of it's way to make things confusing already they don't have NULL, they have NLL. I'm half convinced this is intentional at this point and this is all just some cruel trick by some trickster diety of programming to make an incredible language that is intentionally designed to drive as many people as possible away from using it. Wait... trickster diety, Loki - Odin lang, Odin... checkmate athiests.
I was learning Rust for some time now. I already understood borrowing and the entire ownership model really well but didn't admit I don't get lifetimes at all. Today it finally cliked for me (after 3 months of learning rust :D). It was so obvious and under my nose the entire time! Thank you very much for your amazing explanation! I am incredibly excited to finally dive into Rust completely.
Nice, glad you found the lifetime explanation helpful! I wasn't 100% sure if my explanation was as straightforward as possible, so this anecdote makes me very happy.
Your videos on Rust are well explained and to the point. Plus with the production quality of these video's, it will only take a matter of time before your channel blows up!
Thanks for the kind words Brunkel! I aim to make videos that are engaging but still pack in as much value as possible. I'd love to do this as a full time job, I appreciate you watching as it really helps me toward that goal!
I watched this video about 1 year ago but I didn't understand the lifetime specifier thing at the time. But after 1 year I investigated deeply and asked questions in rust forum and now I completely understand it. Thanks.
Quite dense and fast. I need to rewatch multiple times to let this digest. Although it is not easy, I think It is a good thing. Thanks for the wonderful videos.
@@codetothemoon it really does XD. I'm eager to learn rust and this video made me more interested. this video is pure gold. from the bottom of my heart: thanks you
I just started learning Rust a couple weeks ago and decided to build a calculator in a Yew app. Finally got it up and running last night. I was excited about the ownership concept for similar reasons to what you described due to enormous frustration with trying to rebuild Javascript after encountering runtime errors on runtimes I couldn't test in the development phase. Turns out, it made the calculator thing easier rather than harder by some miracle. I did run into some pretty confusing lifetime errors though. You have to be super careful where you declare things and how long you keep them around, but if you can do that, you're pretty much gold. The whole process for building and deploying a Yew app was a fair bit more enjoyable than React as well. Definitely nicer than wrestling with node_modules.
Shows why I like languages with GC so much. (defn bigger [a b] (if (> a b) a b)) (bigger 3 5) Done. Depends of course on which you prefer or need for the use case: developer performance or code/app performance.
Good stuff :), though your explanation of copy was a bit lacking, it's not just that it's implicit it's also that it requires the memory copy-able one to one, this works great when you have a struct full of primitives since copying the memory is fast, however if your struct contained pointers to heap memory such as box or vec then you wouldn't be able to implement copy since just copying the memory would create a cloned object with the same references. Furthermore copying the struct especially when it only has 1 primitive field is a zero cost abstraction and so it would be no different than giving the print struct a reference.
Jannick - you're so right! Thanks for pointing this out. I'm going to start an errata post and mention this and the incorrect statement I made about segfaults in C++...
Macros are the reason I immediately stopped using Rust after learning it through their book. I knew how to code in Rust, wanted to build something and suddenly nothing made sense anymore because everything was obfuscated by these stupid magic Macros. But apparently that's just something you have to deal with, some libraries just don't want you to know what's really happening.
@@marl3x I think its ‘cargo expand’ which can be used for printing the result of macro expansion in a given program. I think the library developers are prioritizing usability and small code size over understandability, which sadly sometimes are tradeoffs
@@marl3x I don't think I've ever used any third-party macros, only the ones from stdlib and my own. As Rust docs for libraries are auto-generated from code they contain everything either way, so you can usually avoid macros. I know some libraries separate their macros into another optional package as well.
@@marl3x I'm using Rust for years already and I almost never come across libraries, which use macros. I also don't use a lot of macros myself. Almost always, it's been macro specific libraries. Mostly custom derives. If one uses macros, it's not about not wanting the user to know, what's happening internally, it's a simplified syntax for a special purpose. But I also don't like, when I see a library, which forces me to use a lot of weird macros.
I believe the issue with Rust lies not in a lack of understanding about how ownership works, but rather in people's struggle to navigate the limitations it presents. It would be wonderful to come across a video showcasing real-life examples of potential problems and effective strategies for mitigating them.
Yeah I think you're probably right about that. Maybe check out this video on interior mutability - th-cam.com/video/HwupNf9iCJk/w-d-xo.html it might have what you're looking for
Nice. Really love how clearly you explained the concepts - especially the WHY as that makes it easier to peer behind the compiler and understand what's happening - ESPECIALLY with Lifetimes. I'll have to watch a few more times for it to burn into long term memory, but this is the first time I've understood lifetimes 😂
thank you, really happy you got something out of it! i felt like so many people get stuck on these concepts, and there was an easier way of approaching them...
I definitely got tripped up when first encountering the syntax and explanations around this in official docs and other resources. You really broke things down in a beautifully comprehensible way. Thanks so much for the vid!
I have finished the Rust book along with rustlings exercises, which I cannot recommend enough to everyone who wants to learn Rust. But this video was so great at solidifying the concepts I learned! Please do more content like this! *subscribed*
Very good tutorial. I had trouble with moving playing with Rust and despite understanding somehow how it's working, this explains the basic concepts very well. Thanks a lot
The borrow checker makes so much sense, it's surprising that it never got popular before rust. Rust makes me think about memory and types, and the compiler ensures I mostly make correct choices. It feels awesome.
I agree! it's interesting how many recent innovations in software (like the borrow checker) are completely independent of modern hardware and theoretically could have been discovered decades ago. Blockchain and Transformers are also great examples.
Another great video. Lifetimes have been giving me grief and this helped. With 40 years experience programming in at least a dozen languages, these really are the somewhat unique and challenging bits of Rust.
The thing about Rust is it is an incredibly deep and powerful language. And for good reason. But that means that it will take longer to learn than many of the most popular languages out there today. So the productivity curve for a new developer will start off relatively slow, but as they gain experience eventually they will end up being able to build things much more quickly and much higher quality than in other languages.
that's pretty much the same with other languages, like C++ for instances. You start slow that when you gain understanding and experiences your productivity will rose
this was a very helpful video. i already knew how to use lifetimes because i got used to them, but i couldn't have explained how they work. now everything is crystal clear. keep up the good work!
@@codetothemoon these might be a bit niche, but here are a few things I'd like to learn more about in no particular order: - speeding up python code using PyO3 - high-performance/multithreaded data processing with ndarray and polars - speeding up a React/Svelte SPA by writing expensive business logic in Rust and compiling it to WASM - The current status of WASM/WASI and when to expect WASM to get better at DOM manipulation
I started learning Rust a couple weeks ago and had a hard time grasping the concept of Lifetimes... which now I do because of your video! Great content 👌Thanks a lot !!!
Thanks for all your explanatory videos on Rust. I am learning just as much I should from videos without the becoming tutorial dull. I had one question, which I later checked on my own, shouldn't you have removed Clone and Copy Derives after there work was done, it would have removed unnecessary confusions. Keep making these learnable videos without making them into dull tutorial. Thank you again. ❤
Thanks for this video. I tried rust for a while and basically just fumbled with references and lifetime definitions until it did what I want. This video does a good job showing what each of those concepts is so I can be deliberate about my code next time.
Crystal clear explanation. I tried to learn rust a while but everytime I came across borrowing errors I got frustrated and ended up not persuing rust. Maybe after this video I will try again
Didn't realize derive clone was making a copy every time I was passing it to a function call. Oh dear. Should probably avoid that in embedded code. Haven't come across lifetimes yet in my own code, but this was very helpful to understand how they should be implemented and why.
Yeah definitely something to be careful with for performance critical apps... I've only had to deal with struct field lifetimes (which I feel like should be inferred by the compiler instead of needing to explicitly specify) in my real world Rust work - haven't had to do it for function parameters yet. Seems like it's not a common need.
As a C++ Developer i don't understand. Can you please make a video where you explain all this from the compiler implementation side. If you know how a computer works. Implementation Descriptions are usually the best. For me it all seems overkill that gets into the way 99% of the time while saving my arse only in 1% of the time.
The really interesting thing is - I believe borrowing and lifetimes actually don't have any effect on the machine code generated. They only have an impact on whether the program compiles or not - in that sense you might think of them as developer-only abstractions. Re: overkill, Rust definitely isn't for everyone or for all applications.
in rust, when instantiating a `struct` , on the stack, is the variable that we declare is actually a pointer in disguise which also points to data on the stack. like in @1:44. Because, here there is no mentioning about the data (i.e `SomeStruct`) is passed as a reference or by value to the function `print_some_struct`. What we all know by default the data is "moved" to the function, and so the pointer that is initialized earlier is invalid after the function exit (or return).
Thanks for demystifying the lifetime concept. What I didn't get up to this video, was that you introduce the lifetime *in the function* as some form of a guarantee about the variables not going out of scope, but it is the *caller* of the function to make sure this guarantee is upheld .
Great video, I think you should have also explained here about non-lexical lifetimes (at 9:20 you used `bigger` on line 25 to prevent its NLL, but this can confuse many beginners as to why some scenarios don't give an error when you said they should), and also slices (I was very confused about them as a beginner)
what i dont get with the lifetimes is why, with the stuct, example. the compiler can't infer that the reference to the i32 has to live as long as the struct. It literally doesnt work otherwise
One thing you could also do to solve the issue that allows you to do away with the angle brackets in the struct is to define the field as a reference with a lifetime of “‘static” - that’s a reserved lifetime name that says “this lives as long as the program itself.” Only problem there, of course, is that you can leak memory if not careful
I'm a Javascript developer, I'm starting with Rust, I confess that this concept is still a journey for me, besides the difficulty of putting the youtube translator
Nice! Yeah it seems like Diesel has a bit of a learning curve especially if you haven't dealt with automatic schema migration before. But it seems pretty nice once you have a handle on everything.
This is a really great explanation. My only critique would be to try to make a more real world example than the generic examples. I know that always helps me. But I didn’t understand lifetimes until this video.
thanks echobucket! Yeah maybe I should have gone more real world with the example, it's always a tightrope balancing simplicity and brevity with practicality...
lifesaver, the call site examples in main made lifetimes click for me, everyone else seems to avoid that part which is the most important to actually understand it imo.
Thanks, this helped a lot. I have a background in C and I found the error messages refreshingly detailed, but they were kind of cryptic, especially for ownership. I'm used to all function arguments being shallow copies by default and that behaviour was confusing. Having just run into some stack-related lifetime issues in C, these extra checks seem like they could be really nice. I'm not a big fan of the syntax but I like these checks in principle.
It might also be important to note that & references aren't immutable references, they're shared references. The reason these are not being called "immutable" or "read only" references, is in fact because you CAN mutate through them if it's an interior mutable type. (Mutex, RefCell, Atomic types, etc). In these cases, the underlying type ensures that any concurrent access/mutation to the data is safely done. And &mut references are exclusive references (which as you surmised are mutable in this case, that's why they're exclusive).
I learned this ownership & borrowing system (as well as most of the things I know about rust (not a lot)) by making a Compiler for a language that also uses that so I wrote some simple Rust code, compiled it to LLVM IR and tried to understand it. Best learning technique👍
> Rust by default, when you pass a variable into a function, the function takes ownership of the memory for that variable. I like to be a liiitle careful with the wording around move semantics, because folks coming from C or C++ might hear a phrase like "take ownership of memory" and assume everything is happening through pointers. But at the most fundamental level, moves are bitwise copies in Rust, from one location in memory to a _different_ location in memory. When the type in question contains a heap pointer internally, like Vec does, that bitwise copy absolutely is taking ownership of the pointed-to heap memory. But when we move non-Copy types that don't (necessarily) contain heap pointers, like a &mut T or a MutexGuard or a File, the story is a little different.
Very good points, I should have expanded on these things! And in general being more explicit about the distinctions between Rust and more popular languages
Actually, the language Rust adopted borrow semantics (more specifically TypeState) from (Hermes) did indeed by default move data when you assigned it. Rust is the only popular language that works this way, but it's not the only language.
Rust no longer looks weird to me, but it took a while actually. Longer than I thought, but I've been busy with lots of other stuff too... Best way to do it is get going with some framework like axum, bevy, yew, etc. For anyone new out there, I'd recommend just pick a framework and dive into the examples. Of course you need to absorb all the principles over time, but fastest way would be code review so that you can get the main ones down quickly. Too many start rust, then drop it. Many drop it. "System Language" scares people away - though they shouldn't be. It's only "kinda hard" after a bit. Maintainers of the lang, and the community of users should start referring to Rust as a "general purpose language", and not a "system language". Then people will finally come to rust imo.
@Akash Kumar - I've watched some videos on Diesel, but haven't used it yet. Looks nice, but I know it's still a young library, so probably has a ways to go. I just meant understanding the language and getting used to the overall ecosystem, and not getting tripped up what the code is doing. I'm coming from C#, so I had some stuff to learn heading into Rust. I just did several courses, and looked at much source code, and did some notes/refreshing. I feel like I'm way past the hump, but I know there's plenty of things to learn also even with the language itself, but feeling basically comfortable (not expert) took about 2 years because I wasn't just Rust - been in other stuff a lot (3d mostly), which is what others can expect if they are doing other things too. Full time - 6 months, maybe a year. If coming from C++ background, then expect only 3 - 6 months. It will be worth it based on it being challenging to get past hump, so setting yourself apart. Many give up on the training because of time ... You have to commit to it. I've committed to such an extent, I plan on it being my only language.
@Akash Kumar - at this point in time, there aren't many. I'm not looking for a job myself either (doing own thing). The libraries are actually pretty solid, but # of devs - very weak - at this point in time. Rust is such a strong language however that people will be coming - mostly C++ devs, then eventually java/C# crew. Only reason I'm here now is because I left work to train (for a total of almost 4 years now - mostly Blender ... - it takes a while)
I completely agree with everything you said - especially Rust being pigeonholed as a "Systems language" is hugely detrimental. I The reality, like you said, is that it is a perfectly good general purpose that can be used for anything from webapp frontends to games to data science. I've been thinking a lot about how we can help shake this "Only relevant for systems programming" reputation...
@@codetothemoon - Need better courses to be honest. That will come with time as more trainers pick it up. The courses should really be focused on discussing existing rust application and libraries - ie, open up the code and start discussing. See the language first. I think that's the best training method by far. I hate watching people type their code as they're training.
Great quick and concise tutorial. Thank you. At 5:06 you could have deleted the #derive Clone Copy to show that passing by references doesn't implicitly Copy.
Ｈi, thank you for the explanations. In my case, I found that neither of these concepts are esoteric or hard to grasp. My biggest issue is, after I read through the Rust book a couple of times and done some exercises, I still don't know how to proceed. I feel that I have a basketful of disjointed knowledge (for the want of a better word), but I don't know how to put them together to do something useful. For example, a to-do list with a GUI or Web frontend and a mySQL backend. That way people get to learn how to create a simple GUI (with OpenGL or whatever) and how to access a database. Writing a CLI based to-do list that writes to a text file isn't helpful at all. To be more specific about my issue, I am more or less at a total loss as when to do this or that. For example, when to use #derive to derive a trait, when to invoke external crates, and so on. This are things people don't need to worry about with the more traditional languages (pretty much everything else, I think) such as PHP, C, Java, Pascal, etc. Could you provide some suggestions? Thanks in advance!
I take it that, when calling a function with a non-reference argument, the memory used is "moved" from the caller's stack frame, to the called function's stack frame. When the called function returns, without returning the argument, its stack frame, and the argument, disappears. If the argument points to non-stack memory, that memory is cleaned up as part of the called function end.
There are at a lot of other memory save languages, and they are also fast. However, their builders are more focused on optimizing compiler speed and less on internal quarrels.
The thing that seems to hang me up the most with Rust is the ecosystem is huge already and even the standard crate includes so many feature and the only organic way I've been able to learn these things is just by chance seeing someone else use it or someone commenting, "oh you could do that easier if you used xy function from xyz crate". Like, I just learned about chunks on slices in std from someone else. I would've just likely written my own function
There isn’t a single tutorial today that walk through a typical rust project which has global variables, and threads. There are very serious logic flow management related problem you run in projects. Rust focus on to resolve small things and move the problem to a different level. Rust forces you to use Mutexes unnecessarily giving no practical zero overhead alternatives when there are global variables. And there are global variables, always in most of a the applications. It is almost impossible to write a program without any global variable in any language. ( some languages use static as global variables e.g. java )
Great video :) I had this idea for a rust personal project based on some work things. I want to make a CLI tool that syncs a directory with an s3 bucket (paths included) exactly like aws s3 sync does. I got a bit stuck when it came to a) making a proper CLI that takes arguments b) interacting properly with the file system and c) figuring out the aws sdk usage. And of course looking at how the aws cli does the sync already was tricky. Just thought it would be good to break it down some more to try one thing at a time. Each of these things are learning project on their own. I need to get more familiar with these to be able to put them together into something actually useful.
@@codetothemoon I am using the AWS SDK, i found some samples they have on things like accessing S3 that were helpful. But i also looked at rusoto but wasnt sure if its still the go to? using the aws one i managed to list the contents of a bucket so far so good even if the code is a mess 😅, thinking next might be the file system to write the contents of the objects to file. what may get tricky is deciding if the file needs to be replaced or if it matches whats in S3. I think the python CLI only looks at size and time it was created and ignores anything etag related as far as i can tell.
Rust doesn't give every type copy by default unlike in C/C++ where every variable assignment or pass by value means a copy occurs. Like some types must not be copied because they control some singleton or in the case of threads (JoinHandle is not copyable). This forces you to work with these values in a safe way. I would love some more information about how to handle not-copyable types in closures.
Very good video for beginners, i would have liked to see it myself a bit before, when i was struggling to understand and use borrowing and references, but it did make me understand lifetimes well, very good job !
Hi, it’s great video explaining these fundamental powerful feature of rust but I am still not sure about the lifetime, in your example when we are talking about the scope, what we are referring here reference of two structs passed to the function or the real value of two structs?
we're referring to the two structs passed to the function. `other_struct` goes out of scope because it and is inside a block of curly braces, but biggest returns other_struct and assigns it to a variable that is going to live longer than other_struct - this is why we need the lifetime annotations on the function parameters - so that the compiler can catch and flag things like this as errors.
@@codetothemoon when you say the struct passed to the function, you mean the pointer to those structs, right? But since these pointers are borrowed pointers from calling function, these will be taken out of scope by the called function, if we don't specify lifetime, am I right here? If this ia true then what borrowing means here, does it mean pointer is copied and then passed to another function? Because if it is not, then compiler should know the scope of pointer is larger than the called function and we should not need lifetime.
One last thing I don't understand about struct lifetimes: shouldn't lifetimes be implied? Why do you have to declare a generic lifetime 'a for a struct when the compiler should know that the reference field should always live as long as the struct anyway?
ERRATA
* I mention that you get a segfault when you don't deallocate memory in C/C++ - I meant to say that you get a segfault when you try to reference memory that was already deallocated. Not deallocating memory will lead to memory leaks in some cases.
nah still,, a banger video
@@rayahhhmed thanks!
It's not generally true that accessing deallocated memory causes a segfault either. Actually, it would be more helpful if that was the case, since it would be easier to debug than the case where your program is silently accessing data that may or may not be garbage depending on the execution state.
dammit I was gonna yell at you :)
Many embedded systems just use static allocation, so you never deallocate by design.
you dont get a segfault if you dont deallocate memory. Segfaults are when the kernel informs your process that you accesed memory you shouldnt have
ugh, you're absolutely right! This was an egregious mistake. Not deallocating will result in a memory leak. I meant to refer to the case where we erroneously deallocate memory and then try to reference that memory. I'll put a note in the description, thanks for pointing this out!
yo ucan also segfault by accessing memory you never had access to. (in most cases..)
@@GottZ yes I never said that wasnt the caes, I said purely deallocation alone doesnt provoke a segfault directly
@@codetothemoon Also, you can segfault if you correctly deallocate memory and then (because you had more than one reference) you deallocate it again and corrupt the malloc recordkeeping. Sometimes this takes quite a while to blow up on you!
you segfault every time you run your c program for the first time
I like what you are doing here. I am glad that No Boilerplate is influencing people because I am sick of all the stupid presentations in other channels. 1 minute of BS, songs, animations, and people presenting their channels and welcoming as if we were 6 years old watching Ryan's toys reviews.
Thanks! re: the filler stuff - yeah I'm not a fan of lengthy introductions either. I'm not entirely above obnoxious animations (see earlier videos) but I definitely like to get to the point 😎
7:44 In case anyone is wondering why the mutable reference will work if you remove the last `print_some_struct` which uses an immutable reference.
This is because of NLL (non-lexical lifetimes). In short, the compiler infers that it is able to drop the immutable reference borrow before it gets to the mutable reference, because it's not used anywhere later. Thus, you only have one mutable reference, which doesn't break any rules
Great, as if Rust hadn't gone out of it's way to make things confusing already they don't have NULL, they have NLL. I'm half convinced this is intentional at this point and this is all just some cruel trick by some trickster diety of programming to make an incredible language that is intentionally designed to drive as many people as possible away from using it. Wait... trickster diety, Loki - Odin lang, Odin... checkmate athiests.
It's good you mentioned this. This confused me for a long time.
I was learning Rust for some time now. I already understood borrowing and the entire ownership model really well but didn't admit I don't get lifetimes at all. Today it finally cliked for me (after 3 months of learning rust :D). It was so obvious and under my nose the entire time! Thank you very much for your amazing explanation! I am incredibly excited to finally dive into Rust completely.
Nice, glad you found the lifetime explanation helpful! I wasn't 100% sure if my explanation was as straightforward as possible, so this anecdote makes me very happy.
Your videos on Rust are well explained and to the point. Plus with the production quality of these video's, it will only take a matter of time before your channel blows up!
Thanks for the kind words Brunkel! I aim to make videos that are engaging but still pack in as much value as possible. I'd love to do this as a full time job, I appreciate you watching as it really helps me toward that goal!
I watched this video about 1 year ago but I didn't understand the lifetime specifier thing at the time. But after 1 year I investigated deeply and asked questions in rust forum and now I completely understand it. Thanks.
Quite dense and fast. I need to rewatch multiple times to let this digest. Although it is not easy, I think It is a good thing. Thanks for the wonderful videos.
thanks, glad you got something out of it!
Every new rust developer should watch this video,very effective as always.
Thanks! I really do hope this can be a resource for newcomers that removes as much of the friction as possible.
@@codetothemoon it really does XD. I'm eager to learn rust and this video made me more interested. this video is pure gold.
from the bottom of my heart: thanks you
I just started learning Rust a couple weeks ago and decided to build a calculator in a Yew app. Finally got it up and running last night. I was excited about the ownership concept for similar reasons to what you described due to enormous frustration with trying to rebuild Javascript after encountering runtime errors on runtimes I couldn't test in the development phase. Turns out, it made the calculator thing easier rather than harder by some miracle. I did run into some pretty confusing lifetime errors though. You have to be super careful where you declare things and how long you keep them around, but if you can do that, you're pretty much gold. The whole process for building and deploying a Yew app was a fair bit more enjoyable than React as well. Definitely nicer than wrestling with node_modules.
Nice Andy! I love hearing stories like this. I imagine others will have similar experiences
No offense to other youtubers, but this is by far the best explanation on this topic. Specially when it comes to lifetimes. Thanks!
thank you so much for the kind words!
You're the only person on youtube who actually made me understand lifetimes. Thanks!
Great! Really happy you got value out of it!
This was very clear and useful. Best tutorial for rust I've found
thank you, really happy you got value out of it!
This was my second rust video I’ve watched and as a senior coder even I’m amazed at the level of thought that has gone into the language.
I agree! As with any language, there are some aspects I don't like but it's really incredible what the language has accomplished!
Shows why I like languages with GC so much.
(defn bigger [a b]
(if (> a b)
a
b))
(bigger 3 5)
Done. Depends of course on which you prefer or need for the use case: developer performance or code/app performance.
Good stuff :), though your explanation of copy was a bit lacking, it's not just that it's implicit it's also that it requires the memory copy-able one to one, this works great when you have a struct full of primitives since copying the memory is fast, however if your struct contained pointers to heap memory such as box or vec then you wouldn't be able to implement copy since just copying the memory would create a cloned object with the same references.
Furthermore copying the struct especially when it only has 1 primitive field is a zero cost abstraction and so it would be no different than giving the print struct a reference.
Jannick - you're so right! Thanks for pointing this out. I'm going to start an errata post and mention this and the incorrect statement I made about segfaults in C++...
Wow, this is a brilliant video! I had some trouble with the borrowing, but now I've got it, thanks to you! 💡
fantastic, really happy this particular approach made things clearer for you!
Would like to see one on Procedural Macros as well. They are essentially magic to me right now.
Great idea Soumen! In fact I have this in the works already, it might be the next video.
Macros are the reason I immediately stopped using Rust after learning it through their book.
I knew how to code in Rust, wanted to build something and suddenly nothing made sense anymore because everything was obfuscated by these stupid magic Macros. But apparently that's just something you have to deal with, some libraries just don't want you to know what's really happening.
@@marl3x I think its ‘cargo expand’ which can be used for printing the result of macro expansion in a given program. I think the library developers are prioritizing usability and small code size over understandability, which sadly sometimes are tradeoffs
@@marl3x I don't think I've ever used any third-party macros, only the ones from stdlib and my own. As Rust docs for libraries are auto-generated from code they contain everything either way, so you can usually avoid macros. I know some libraries separate their macros into another optional package as well.
@@marl3x I'm using Rust for years already and I almost never come across libraries, which use macros.
I also don't use a lot of macros myself.
Almost always, it's been macro specific libraries. Mostly custom derives.
If one uses macros, it's not about not wanting the user to know, what's happening internally, it's a simplified syntax for a special purpose.
But I also don't like, when I see a library, which forces me to use a lot of weird macros.
These were indeed exactly the parts that were hard to get used to as someone who is used to GC collected languages. Very useful tutorial.
Thanks Qaz, glad you found it valuable!
This was great, I love how you gave actual examples for the things the compiler was complaining about.
Thanks Gazareth, glad you found it valuable!
I believe the issue with Rust lies not in a lack of understanding about how ownership works, but rather in people's struggle to navigate the limitations it presents. It would be wonderful to come across a video showcasing real-life examples of potential problems and effective strategies for mitigating them.
Yeah I think you're probably right about that. Maybe check out this video on interior mutability - th-cam.com/video/HwupNf9iCJk/w-d-xo.html it might have what you're looking for
Nice. Really love how clearly you explained the concepts - especially the WHY as that makes it easier to peer behind the compiler and understand what's happening - ESPECIALLY with Lifetimes. I'll have to watch a few more times for it to burn into long term memory, but this is the first time I've understood lifetimes 😂
thank you, really happy you got something out of it! i felt like so many people get stuck on these concepts, and there was an easier way of approaching them...
Amazing just got fed up with JS for the eleventh time this week and started reading rust docs and now this, thanks!
Thanks Tobias, I really appreciate you watching each video!
I definitely got tripped up when first encountering the syntax and explanations around this in official docs and other resources. You really broke things down in a beautifully comprehensible way. Thanks so much for the vid!
thanks, really happy you liked it!
I have finished the Rust book along with rustlings exercises, which I cannot recommend enough to everyone who wants to learn Rust. But this video was so great at solidifying the concepts I learned! Please do more content like this! *subscribed*
The Rust Book is fantastic! More videos on the way. Very Happy to have you onboard!
What's wrong with rustlings? I wanted to try it.
@@egorandreevich7830 Nothing, rustlings exercises are wonderful
@@mbrav so why you cannot recommend it?
@@egorandreevich7830 I cannot recommend it ENOUGH. Meaning is inversed.
Very good tutorial. I had trouble with moving playing with Rust and despite understanding somehow how it's working, this explains the basic concepts very well. Thanks a lot
nice, really happy it was helpful!
Very clear explanations and straight to the point. This the best 14 minutes of my rust journey so far.
thank you, glad you got something out of it!
I've watched many channels, but yours is by far the best explanation style I've seen so far! Kudos bro.
Magicccc!! we need more of these short videos. Great job :)
Thanks void, more to come!
The borrow checker makes so much sense, it's surprising that it never got popular before rust. Rust makes me think about memory and types, and the compiler ensures I mostly make correct choices. It feels awesome.
I agree! it's interesting how many recent innovations in software (like the borrow checker) are completely independent of modern hardware and theoretically could have been discovered decades ago. Blockchain and Transformers are also great examples.
Great video. You just made me to try clean my laptop screen with that grey line on your camera background 😅.
Thanks and hah! Green screen keying is tricky to get exactly right sometimes.... 🙃
So much effort to return a variable!
hah! luckily it's a bit of a corner case...
Another great video. Lifetimes have been giving me grief and this helped. With 40 years experience programming in at least a dozen languages, these really are the somewhat unique and challenging bits of Rust.
Thanks Rich, really happy you found it helpful!
The thing about Rust is it is an incredibly deep and powerful language. And for good reason. But that means that it will take longer to learn than many of the most popular languages out there today. So the productivity curve for a new developer will start off relatively slow, but as they gain experience eventually they will end up being able to build things much more quickly and much higher quality than in other languages.
agree! 💯
that's pretty much the same with other languages, like C++ for instances. You start slow that when you gain understanding and experiences your productivity will rose
Great video! I really feel like I've understood borrowing and lifetimes for the first time since the first time I was rust-curious a year ago
Thanks Pat, really happy this helped clear up the confusion around these concepts!
My golden rule:
- borrowed value as fn params
- return value
yep that's definitely a common scenario!
This channel is a blessing
Very happy to have you onboard!
this was a very helpful video. i already knew how to use lifetimes because i got used to them, but i couldn't have explained how they work. now everything is crystal clear. keep up the good work!
glad it was helpful, and thank you!
Great pacing and presentation - quickly becoming one of my favorite Rust channels
Thanks for the kind words! If there are any topics you'd like to see let me know!
@@codetothemoon these might be a bit niche, but here are a few things I'd like to learn more about in no particular order:
- speeding up python code using PyO3
- high-performance/multithreaded data processing with ndarray and polars
- speeding up a React/Svelte SPA by writing expensive business logic in Rust and compiling it to WASM
- The current status of WASM/WASI and when to expect WASM to get better at DOM manipulation
I started learning Rust a couple weeks ago and had a hard time grasping the concept of Lifetimes... which now I do because of your video! Great content 👌Thanks a lot !!!
Nice Jorge! Glad you found the video helpful!
I think I finally understand lifetimes. Simple and elegant. Thank you!
Nice, glad you found the video helpful, thanks for watching!
Thanks for all your explanatory videos on Rust. I am learning just as much I should from videos without the becoming tutorial dull.
I had one question, which I later checked on my own, shouldn't you have removed Clone and Copy Derives after there work was done, it would have removed unnecessary confusions.
Keep making these learnable videos without making them into dull tutorial. Thank you again. ❤
Incredibly easy to understand and straight to the point video, keep up the good work!
Thanks, glad you found it valuable!
Thanks for this video. I tried rust for a while and basically just fumbled with references and lifetime definitions until it did what I want. This video does a good job showing what each of those concepts is so I can be deliberate about my code next time.
nice, really happy you got something out of the video! 😎
Really it's a great video , keep going and we wand bigger projects 💙🔥
Thanks Hamdy! Bigger projects are on the way!
Crystal clear explanation. I tried to learn rust a while but everytime I came across borrowing errors I got frustrated and ended up not persuing rust. Maybe after this video I will try again
Thanks Nova, glad you found it valuable!
Didn't realize derive clone was making a copy every time I was passing it to a function call. Oh dear. Should probably avoid that in embedded code. Haven't come across lifetimes yet in my own code, but this was very helpful to understand how they should be implemented and why.
Yeah definitely something to be careful with for performance critical apps... I've only had to deal with struct field lifetimes (which I feel like should be inferred by the compiler instead of needing to explicitly specify) in my real world Rust work - haven't had to do it for function parameters yet. Seems like it's not a common need.
As a C++ Developer i don't understand. Can you please make a video where you explain all this from the compiler implementation side. If you know how a computer works. Implementation Descriptions are usually the best. For me it all seems overkill that gets into the way 99% of the time while saving my arse only in 1% of the time.
The really interesting thing is - I believe borrowing and lifetimes actually don't have any effect on the machine code generated. They only have an impact on whether the program compiles or not - in that sense you might think of them as developer-only abstractions. Re: overkill, Rust definitely isn't for everyone or for all applications.
Excelent explanation!, really loved it! it's very concise and to the point
Thanks Luis, glad you found it valuable!
in rust, when instantiating a `struct` , on the stack, is the variable that we declare is actually a pointer in disguise which also points to data on the stack. like in @1:44. Because, here there is no mentioning about the data (i.e `SomeStruct`) is passed as a reference or by value to the function `print_some_struct`. What we all know by default the data is "moved" to the function, and so the pointer that is initialized earlier is invalid after the function exit (or return).
Thanks for demystifying the lifetime concept. What I didn't get up to this video, was that you introduce the lifetime *in the function* as some form of a guarantee about the variables not going out of scope, but it is the *caller* of the function to make sure this guarantee is upheld .
thanks for the clear and concise video!
Thanks Carrot! It'd be fair to attribute at least some of that clarity to your abundant levels of vitamin A!
I would love a bigger video on this with a focus on examples! Great vid
Thanks, bigger examples are on the way!
Great video, I think you should have also explained here about non-lexical lifetimes (at 9:20 you used `bigger` on line 25 to prevent its NLL, but this can confuse many beginners as to why some scenarios don't give an error when you said they should), and also slices (I was very confused about them as a beginner)
Great points - I'd love to go into lifetimes in more detail in a future video. Slices too!
this really helped me a lot understanding these concepts. ...huge THANK YOU!!!
glad you found it valuable, thanks for watching!
what i dont get with the lifetimes is why, with the stuct, example. the compiler can't infer that the reference to the i32 has to live as long as the struct. It literally doesnt work otherwise
One thing you could also do to solve the issue that allows you to do away with the angle brackets in the struct is to define the field as a reference with a lifetime of “‘static” - that’s a reserved lifetime name that says “this lives as long as the program itself.”
Only problem there, of course, is that you can leak memory if not careful
Good point, I think that is a potential approach too, if your program allows for it
@@codetothemoon OS kernel is definitely something that does, so yes.
I'm a Javascript developer, I'm starting with Rust, I confess that this concept is still a journey for me, besides the difficulty of putting the youtube translator
It's a journey that can feel a bit slow at first but imo is well worth it!
Great video. Really clear explanation.
Thanks, very happy you found it valuable!
Killer video. Bet this guys channel blows up if he keeps making content in this style
Thanks Jacob, I hope you're right!
Been building a project in actix Web with Diesel.....seriously, Diesel is insanely easy to setup and running DB queries on Rust is a charm....
Nice! Yeah it seems like Diesel has a bit of a learning curve especially if you haven't dealt with automatic schema migration before. But it seems pretty nice once you have a handle on everything.
Loved it, thanks for the explanation
Thanks for watching Abishek!
This is a really great explanation. My only critique would be to try to make a more real world example than the generic examples. I know that always helps me. But I didn’t understand lifetimes until this video.
thanks echobucket! Yeah maybe I should have gone more real world with the example, it's always a tightrope balancing simplicity and brevity with practicality...
lifesaver, the call site examples in main made lifetimes click for me, everyone else seems to avoid that part which is the most important to actually understand it imo.
Nice, glad the example helped! I agree, it's really difficult to understand lifetimes without the context around how the function is actually invoked.
Are those box switches on your keyboard? :D
pretty sure I used the Redragon K552 with blue (clicky) switches for this one
Excellent explanation!!! keep doing more videos like this!!
thanks, more to come!
Thanks, this helped a lot. I have a background in C and I found the error messages refreshingly detailed, but they were kind of cryptic, especially for ownership. I'm used to all function arguments being shallow copies by default and that behaviour was confusing. Having just run into some stack-related lifetime issues in C, these extra checks seem like they could be really nice. I'm not a big fan of the syntax but I like these checks in principle.
It might also be important to note that & references aren't immutable references, they're shared references. The reason these are not being called "immutable" or "read only" references, is in fact because you CAN mutate through them if it's an interior mutable type. (Mutex, RefCell, Atomic types, etc). In these cases, the underlying type ensures that any concurrent access/mutation to the data is safely done.
And &mut references are exclusive references (which as you surmised are mutable in this case, that's why they're exclusive).
I learned this ownership & borrowing system (as well as most of the things I know about rust (not a lot)) by making a Compiler for a language that also uses that so I wrote some simple Rust code, compiled it to LLVM IR and tried to understand it. Best learning technique👍
> Rust by default, when you pass a variable into a function, the function takes ownership of the memory for that variable.
I like to be a liiitle careful with the wording around move semantics, because folks coming from C or C++ might hear a phrase like "take ownership of memory" and assume everything is happening through pointers. But at the most fundamental level, moves are bitwise copies in Rust, from one location in memory to a _different_ location in memory. When the type in question contains a heap pointer internally, like Vec does, that bitwise copy absolutely is taking ownership of the pointed-to heap memory. But when we move non-Copy types that don't (necessarily) contain heap pointers, like a &mut T or a MutexGuard or a File, the story is a little different.
Very good points, I should have expanded on these things! And in general being more explicit about the distinctions between Rust and more popular languages
Actually, the language Rust adopted borrow semantics (more specifically TypeState) from (Hermes) did indeed by default move data when you assigned it. Rust is the only popular language that works this way, but it's not the only language.
Whoa I wasn't aware of Hermes, I stand corrected!
Rust no longer looks weird to me, but it took a while actually. Longer than I thought, but I've been busy with lots of other stuff too... Best way to do it is get going with some framework like axum, bevy, yew, etc. For anyone new out there, I'd recommend just pick a framework and dive into the examples. Of course you need to absorb all the principles over time, but fastest way would be code review so that you can get the main ones down quickly. Too many start rust, then drop it. Many drop it. "System Language" scares people away - though they shouldn't be. It's only "kinda hard" after a bit. Maintainers of the lang, and the community of users should start referring to Rust as a "general purpose language", and not a "system language". Then people will finally come to rust imo.
@Akash Kumar - I've watched some videos on Diesel, but haven't used it yet. Looks nice, but I know it's still a young library, so probably has a ways to go. I just meant understanding the language and getting used to the overall ecosystem, and not getting tripped up what the code is doing. I'm coming from C#, so I had some stuff to learn heading into Rust. I just did several courses, and looked at much source code, and did some notes/refreshing. I feel like I'm way past the hump, but I know there's plenty of things to learn also even with the language itself, but feeling basically comfortable (not expert) took about 2 years because I wasn't just Rust - been in other stuff a lot (3d mostly), which is what others can expect if they are doing other things too. Full time - 6 months, maybe a year. If coming from C++ background, then expect only 3 - 6 months. It will be worth it based on it being challenging to get past hump, so setting yourself apart. Many give up on the training because of time ... You have to commit to it. I've committed to such an extent, I plan on it being my only language.
@Akash Kumar - at this point in time, there aren't many. I'm not looking for a job myself either (doing own thing). The libraries are actually pretty solid, but # of devs - very weak - at this point in time. Rust is such a strong language however that people will be coming - mostly C++ devs, then eventually java/C# crew. Only reason I'm here now is because I left work to train (for a total of almost 4 years now - mostly Blender ... - it takes a while)
Jeff - that's really cool - do you do modeling in Blender or do you use the Python APIs to make generative art?
I completely agree with everything you said - especially Rust being pigeonholed as a "Systems language" is hugely detrimental. I The reality, like you said, is that it is a perfectly good general purpose that can be used for anything from webapp frontends to games to data science.
I've been thinking a lot about how we can help shake this "Only relevant for systems programming" reputation...
@@codetothemoon - Need better courses to be honest. That will come with time as more trainers pick it up. The courses should really be focused on discussing existing rust application and libraries - ie, open up the code and start discussing. See the language first. I think that's the best training method by far. I hate watching people type their code as they're training.
This is so easy for people who worked with pointers before. Really says a lot about the state of programming nowadays
glad to hear that it's easy for some - I personally found it a bit challenging to grasp at first despite having substantial C++ experience
@@codetothemoon Maybe because you don't had anyone to explain it to you through examples?
Thank you for your videos! Really want to watch video about traits and derive from you.
Glad you found them valuable! I'll put traits and derive on the video ideas list!
Very clear explanation. Thank you.
Thanks for watching Tuan!
Great quick and concise tutorial. Thank you.
At 5:06 you could have deleted the #derive Clone Copy to show that passing by references doesn't implicitly Copy.
Thanks for watching! And good point, I probably should have done that
I wish I watched this 5 years ago...
after 300k LOC I watched this just for pleasure - by the way, the video is well-paced.
Thanks!
Thanks Bohdan! You have far more Rust LOCs under your belt than I, so your seal of approval is much appreciated!
Thanks for simplifying the difficult parts!
glad you found it valuable!
Ｈi, thank you for the explanations. In my case, I found that neither of these concepts are esoteric or hard to grasp. My biggest issue is, after I read through the Rust book a couple of times and done some exercises, I still don't know how to proceed.
I feel that I have a basketful of disjointed knowledge (for the want of a better word), but I don't know how to put them together to do something useful. For example, a to-do list with a GUI or Web frontend and a mySQL backend. That way people get to learn how to create a simple GUI (with OpenGL or whatever) and how to access a database. Writing a CLI based to-do list that writes to a text file isn't helpful at all.
To be more specific about my issue, I am more or less at a total loss as when to do this or that. For example, when to use #derive to derive a trait, when to invoke external crates, and so on. This are things people don't need to worry about with the more traditional languages (pretty much everything else, I think) such as PHP, C, Java, Pascal, etc.
Could you provide some suggestions? Thanks in advance!
Very well delivered and easy to follow! Thank you!
thanks maxreuv, glad you found it valuable!
I take it that, when calling a function with a non-reference argument, the memory used is "moved" from the caller's stack frame, to the called function's stack frame. When the called function returns, without returning the argument, its stack frame, and the argument, disappears. If the argument points to non-stack memory, that memory is cleaned up as part of the called function end.
This was incredibly useful, thanks a lot!
nice, really happy you found it valuable!
Just the video i was looking for ...awesome!
thanks, glad you got something out of it!
There are at a lot of other memory save languages, and they are also fast. However, their builders are more focused on optimizing compiler speed and less on internal quarrels.
The thing that seems to hang me up the most with Rust is the ecosystem is huge already and even the standard crate includes so many feature and the only organic way I've been able to learn these things is just by chance seeing someone else use it or someone commenting, "oh you could do that easier if you used xy function from xyz crate". Like, I just learned about chunks on slices in std from someone else. I would've just likely written my own function
Thank you for this! I really love your content and would like to see more.
Thanks for watching, more is on the way!
got the concepts,thank you very much!
nice, thanks for watching!
Thank you for the indexed video!
Thanks for watching Jambang!
I've finally understood it! THANKS
nice! really happy you got something out of it!
Thank you so much! I've finally understood the lifetime.
Thanks for watching Chan, glad you found it valuable!
Very well explained, thank you!
Thanks for watching, glad you found it valuable!
great lecture!! thank you so much
thanks, glad you found it valuable!
It's funny for me the borrow checker , lifetimes are the easiest part. What is hard for me is actually understangind the syntax of nested matches
hah, yeah those can get pretty hairy!
There isn’t a single tutorial today that walk through a typical rust project which has global variables, and threads. There are very serious logic flow management related problem you run in projects.
Rust focus on to resolve small things and move the problem to a different level.
Rust forces you to use Mutexes unnecessarily giving no practical zero overhead alternatives when there are global variables. And there are global variables, always in most of a the applications. It is almost impossible to write a program without any global variable in any language. ( some languages use static as global variables e.g. java )
Great video :) I had this idea for a rust personal project based on some work things. I want to make a CLI tool that syncs a directory with an s3 bucket (paths included) exactly like aws s3 sync does. I got a bit stuck when it came to a) making a proper CLI that takes arguments b) interacting properly with the file system and c) figuring out the aws sdk usage. And of course looking at how the aws cli does the sync already was tricky. Just thought it would be good to break it down some more to try one thing at a time. Each of these things are learning project on their own. I need to get more familiar with these to be able to put them together into something actually useful.
Thanks Daniel! an s3 sync CLI tool actually sounds like a perfect project to learn Rust. Are you using the official Rust AWS SDK or Rusoto?
@@codetothemoon I am using the AWS SDK, i found some samples they have on things like accessing S3 that were helpful. But i also looked at rusoto but wasnt sure if its still the go to? using the aws one i managed to list the contents of a bucket so far so good even if the code is a mess 😅, thinking next might be the file system to write the contents of the objects to file. what may get tricky is deciding if the file needs to be replaced or if it matches whats in S3. I think the python CLI only looks at size and time it was created and ignores anything etag related as far as i can tell.
To avoid confuision, at 5:25 it'll be good to remove the derived Clone and Copy. These are no longer needed.
Rust doesn't give every type copy by default unlike in C/C++ where every variable assignment or pass by value means a copy occurs. Like some types must not be copied because they control some singleton or in the case of threads (JoinHandle is not copyable). This forces you to work with these values in a safe way. I would love some more information about how to handle not-copyable types in closures.
Very good video for beginners, i would have liked to see it myself a bit before, when i was struggling to understand and use borrowing and references, but it did make me understand lifetimes well, very good job !
thanks ziii, glad you found it valuable!
Hi, it’s great video explaining these fundamental powerful feature of rust but I am still not sure about the lifetime, in your example when we are talking about the scope, what we are referring here reference of two structs passed to the function or the real value of two structs?
we're referring to the two structs passed to the function. `other_struct` goes out of scope because it and is inside a block of curly braces, but biggest returns other_struct and assigns it to a variable that is going to live longer than other_struct - this is why we need the lifetime annotations on the function parameters - so that the compiler can catch and flag things like this as errors.
@@codetothemoon when you say the struct passed to the function, you mean the pointer to those structs, right? But since these pointers are borrowed pointers from calling function, these will be taken out of scope by the called function, if we don't specify lifetime, am I right here?
If this ia true then what borrowing means here, does it mean pointer is copied and then passed to another function? Because if it is not, then compiler should know the scope of pointer is larger than the called function and we should not need lifetime.
One last thing I don't understand about struct lifetimes: shouldn't lifetimes be implied? Why do you have to declare a generic lifetime 'a for a struct when the compiler should know that the reference field should always live as long as the struct anyway?
I completely agree with this - I'm not sure why these need to be explicitly specified! was thinking about posting about it in r/rust...