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.
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 😎
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.
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!
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!
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.
@@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.
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 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.
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*
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...
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++...
2:18 "In C and C++, you do have to worry about deallocating memory. And if you don't deallocate memory in C and C++, you're gonna get a segfault." 1. In C++, you have RAII, allowing many data types to deallocate their own memory for you simply by going out of scope. 2. Failure to deallocate memory will, generally speaking, not lead to a segfault. It will lead to a memory leak. 3. The issue that Rust's ownership system is solving over C and C++ is use after free, not failure to free.
Thanks for pointing this out! A few others have pointed it out as well, and it was an egregious error on my part. I meant to say something to the effect of "using a dangling pointer after the referenced memory has been deallocated cause a segfault". I've never wanted TH-cam to have some kind of video "patch" mechanism so badly... I have a question about #3 - doesn't Rust address failure to free as well? By basically not allowing "dumb" pointers in non "unsafe" code. Ie you're never expected to explicitly deallocate memory like you have to in some cases in C/C++ ("new" and subsequent "delete).
@@codetothemoon Rust has RAII like C++, but this only solves failure to free in the majority of cases. It is relatively trivial to create a memory leak using cyclical reference counted data types. This is discussed explicitly in the Rust Book, chapter 15.6 (Reference Cycles Can Leak Memory).
@@laviray5447 That would be correct, you are using memory after it has been freed. Suppose I have a pointer, which shall be called p, in a C program. p points to a block of memory allocated with malloc. Over the course of my program, I make a few copies of p for various data structures, and eventually, when I assume there are no valid pointers left but p, I call free on it to make that memory usable for other calls to malloc. Fool that I am, I still had copies of p available, and later in the program, they are dereferenced, yielding either a segfault, or whatever was stored there after subsequent mallocs. The memory address has been used after the memory allocated there was freed, leading to undefined behavior. Rust's ownership system makes this type of bug impossible without the use of unsafe.
accessing any place without a value. it must be inaccessible. a pointer is a door to it. all doors must be closed. Rust closes the doors for you. C++ doesn’t. With no benefit.
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!
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.
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!
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 !!!
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.
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. ❤
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
@@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
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.
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.
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, 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.
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👍
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 .
Rust is basically "looking to garbage collect" memory at compile time and tells you that you're messing with it. At least that's how I feel about the borrowing system.
that's one way to look at it! another might be it's looking to deallocate memory immediately after that memory is no longer being used, and the borrowing rules are the means by which it is able to know when something is no longer being used
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.
> 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
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 !
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.
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
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.
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.
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.
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
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).
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 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)
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 )
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?
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
Every time i’m watching any video here i keep , get fantasized about the keyboard sound and the speed of the typing, to the extent that i lose focus on the video 😂
Ｈ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!
thanks for creating this video, i undestand mostly lifestime and reference, borrow is still shallow to me, i started to lean rust, read a few paper of the rust doc, maybe should start writing some simple program to learn those concept
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 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.
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.
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 😎
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.
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
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!
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.
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
You're the only person on youtube who actually made me understand lifetimes. Thanks!
Great! Really happy you got value out of it!
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.
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.
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!
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 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.
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...
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++...
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!
2:18 "In C and C++, you do have to worry about deallocating memory. And if you don't deallocate memory in C and C++, you're gonna get a segfault."
1. In C++, you have RAII, allowing many data types to deallocate their own memory for you simply by going out of scope.
2. Failure to deallocate memory will, generally speaking, not lead to a segfault. It will lead to a memory leak.
3. The issue that Rust's ownership system is solving over C and C++ is use after free, not failure to free.
Thanks for pointing this out! A few others have pointed it out as well, and it was an egregious error on my part. I meant to say something to the effect of "using a dangling pointer after the referenced memory has been deallocated cause a segfault". I've never wanted TH-cam to have some kind of video "patch" mechanism so badly...
I have a question about #3 - doesn't Rust address failure to free as well? By basically not allowing "dumb" pointers in non "unsafe" code. Ie you're never expected to explicitly deallocate memory like you have to in some cases in C/C++ ("new" and subsequent "delete).
@@codetothemoon Rust has RAII like C++, but this only solves failure to free in the majority of cases. It is relatively trivial to create a memory leak using cyclical reference counted data types. This is discussed explicitly in the Rust Book, chapter 15.6 (Reference Cycles Can Leak Memory).
Can you please elaborate on what you mean by "use after free"? Do you mean not allowing to use a memory after it had been already freed?
@@laviray5447 That would be correct, you are using memory after it has been freed. Suppose I have a pointer, which shall be called p, in a C program. p points to a block of memory allocated with malloc. Over the course of my program, I make a few copies of p for various data structures, and eventually, when I assume there are no valid pointers left but p, I call free on it to make that memory usable for other calls to malloc. Fool that I am, I still had copies of p available, and later in the program, they are dereferenced, yielding either a segfault, or whatever was stored there after subsequent mallocs. The memory address has been used after the memory allocated there was freed, leading to undefined behavior.
Rust's ownership system makes this type of bug impossible without the use of unsafe.
accessing any place without a value. it must be inaccessible. a pointer is a door to it. all doors must be closed.
Rust closes the doors for you.
C++ doesn’t. With no benefit.
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!
I've watched many channels, but yours is by far the best explanation style I've seen so far! Kudos bro.
This was very clear and useful. Best tutorial for rust I've found
thank you, really happy you got value out of it!
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!
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!
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!
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 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!
Incredibly easy to understand and straight to the point video, keep up the good work!
Thanks, glad you found it valuable!
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!
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.
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!
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 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!
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
This channel is a blessing
Very happy to have you onboard!
I think I finally understand lifetimes. Simple and elegant. Thank you!
Nice, glad you found the video helpful, thanks for watching!
Excelent explanation!, really loved it! it's very concise and to the point
Thanks Luis, glad you found it valuable!
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
So much effort to return a variable!
hah! luckily it's a bit of a corner case...
Magicccc!! we need more of these short videos. Great job :)
Thanks void, more to come!
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.... 🙃
Great video. Really clear explanation.
Thanks, very happy you found it valuable!
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.
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.
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!
Excellent explanation!!! keep doing more videos like this!!
thanks, more to come!
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?
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.
Really it's a great video , keep going and we wand bigger projects 💙🔥
Thanks Hamdy! Bigger projects are on the way!
Just the video i was looking for ...awesome!
thanks, glad you got something out of it!
this really helped me a lot understanding these concepts. ...huge THANK YOU!!!
glad you found it valuable, thanks for watching!
Very clear explanation. Thank you.
Thanks for watching Tuan!
got the concepts,thank you very much!
nice, thanks for watching!
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👍
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 .
This was incredibly useful, thanks a lot!
nice, really happy you found it valuable!
Thank you for the indexed video!
Thanks for watching Jambang!
I would love a bigger video on this with a focus on examples! Great vid
Thanks, bigger examples are on the way!
Rust is basically "looking to garbage collect" memory at compile time and tells you that you're messing with it. At least that's how I feel about the borrowing system.
that's one way to look at it! another might be it's looking to deallocate memory immediately after that memory is no longer being used, and the borrowing rules are the means by which it is able to know when something is no longer being used
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!
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.
> 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
Killer video. Bet this guys channel blows up if he keeps making content in this style
Thanks Jacob, I hope you're right!
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!
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.
Thank you for this! I really love your content and would like to see more.
Thanks for watching, more is on the way!
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 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
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.
most make-sense explanation of lifetimes i've seen.
fantastic, thank you! 😎
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.
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
Very well delivered and easy to follow! Thank you!
thanks maxreuv, 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).
The cleanest explanation I've seen on YT.
Thanks pvc!
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.
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!
Very well explained, thank you!
Thanks for watching, glad you found it valuable!
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 )
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!
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...
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 think I found my new favorite Rust channel.
Nice, very happy to have you onboard!
Excellent video, thanks!
thanks, glad you got something out of it!
Every time i’m watching any video here i keep , get fantasized about the keyboard sound and the speed of the typing, to the extent that i lose focus on the video 😂
lol - I may have a keyboard video in the works that you may enjoy 😎
Ｈ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!
Thank you. Amazingly explained.
Great cover ! Thanks
Thanks for watching!
Thanks for amazing explanation.
very happy you got something out of it!
thanks for creating this video, i undestand mostly lifestime and reference, borrow is still shallow to me, i started to lean rust, read a few paper of the rust doc, maybe should start writing some simple program to learn those concept
this is explanation to the moon. Keep the tutorials coming. Thanks :)
glad you found it valuable, more are on the way!
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!
Thank you this helped a lot!
Nice, glad you found it valuable Abhinand!
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
Welp. I need to bookmark this video. I'm working on a semi-serious project and lifetimes are the exact thing I'm stuck on
Nice Neoplumes! Glad the video came in handy!
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.
simply and useful. thank you
nice, glad you got something out of it!
Very good and straight to the point. I'll still need some effort to understand these concepts, though. But, if I can get rid of C++, it's worth it :D
Thanks C Forester! C++ was my first language, and I think Rust is a very worthy successor.
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!
My golden rule:
- borrowed value as fn params
- return value
yep that's definitely a common scenario!