Rust Demystified 🪄 Simplifying The Toughest Parts

[@codetothemoon]

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.

[@rayahhhmed]

nah still,, a banger video

[@codetothemoon]

@@rayahhhmed thanks!

[@AGBuzz182]

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.

[@MikaelMurstam]

dammit I was gonna yell at you :)

[@patricklittle1002]

Many embedded systems just use static allocation, so you never deallocate by design.

[@abraham7966]

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.

[@codetothemoon]

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 😎

[@cathalogrady2331]

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

[@codetothemoon]

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!

[@GottZ]

yo ucan also segfault by accessing memory you never had access to. (in most cases..)

[@cathalogrady2331]

@@GottZ yes I never said that wasnt the caes, I said purely deallocation alone doesnt provoke a segfault directly

[@pinealservo]

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

[@hotpawsmathsandscience3124]

you segfault every time you run your c program for the first time

[@megumin4625]

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

[@robonator2945]

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.

[@z4nshin]

It's good you mentioned this. This confused me for a long time.

[@lukakralik2346]

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.

[@codetothemoon]

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.

[@InMemoryOfNeo]

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.

[@mdshohidurrahman1121]

Every new rust developer should watch this video,very effective as always.

[@codetothemoon]

Thanks! I really do hope this can be a resource for newcomers that removes as much of the friction as possible.

[@emiliorojas583]

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

[@Chuukwudi]

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]

thanks, glad you got something out of it!

[@brunkel8269]

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!

[@codetothemoon]

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!

[@antoniofornie]

No offense to other youtubers, but this is by far the best explanation on this topic. Specially when it comes to lifetimes. Thanks!

[@codetothemoon]

thank you so much for the kind words!

[@filipskoras]

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.

[@codetothemoon]

Yeah I think you're probably right about that. Maybe check out this video on interior mutability - kzbin.info/www/bejne/fqjYoYGcbs52gM0 it might have what you're looking for

[@andythedishwasher1117]

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.

[@codetothemoon]

Nice Andy! I love hearing stories like this. I imagine others will have similar experiences

[@cracktek_industries]

You're the only person on youtube who actually made me understand lifetimes. Thanks!

[@codetothemoon]

Great! Really happy you got value out of it!

[@achimwasp]

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.

[@thisoldproperty]

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.

[@codetothemoon]

I agree! As with any language, there are some aspects I don't like but it's really incredible what the language has accomplished!

[@smashingtonn]

This was very clear and useful. Best tutorial for rust I've found

[@codetothemoon]

thank you, really happy you got value out of it!

[@soumen_pradhan]

Would like to see one on Procedural Macros as well. They are essentially magic to me right now.

[@codetothemoon]

Great idea Soumen! In fact I have this in the works already, it might be the next video.

[@marl3x]

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.

[@erikfundercarstensen7344]

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

[@SaHaRaSquad]

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

[@porky1118]

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

[@KnightMirkoYo]

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.

[@codetothemoon]

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.

[@QazCetelic]

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.

[@codetothemoon]

Thanks Qaz, glad you found it valuable!

[@LukasRotermund]

Wow, this is a brilliant video! I had some trouble with the borrowing, but now I've got it, thanks to you! 💡

[@codetothemoon]

fantastic, really happy this particular approach made things clearer for you!

[@tobias3581]

Amazing just got fed up with JS for the eleventh time this week and started reading rust docs and now this, thanks!

[@codetothemoon]

Thanks Tobias, I really appreciate you watching each video!

[@mrhoxell]

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

[@codetothemoon]

nice, really happy it was helpful!

[@sharperguy]

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.

[@codetothemoon]

agree! 💯

[@keludgraphica80]

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

[@mbrav]

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*

[@codetothemoon]

The Rust Book is fantastic! More videos on the way. Very Happy to have you onboard!

[@egorandreevich7830]

What's wrong with rustlings? I wanted to try it.

[@mbrav]

@@egorandreevich7830 Nothing, rustlings exercises are wonderful

[@egorandreevich7830]

​@@mbrav so why you cannot recommend it?

[@mbrav]

@@egorandreevich7830 I cannot recommend it ENOUGH. Meaning is inversed.

[@TheRealAfroRick]

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 😂

[@codetothemoon]

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

[@user-vs9uf3ny8z]

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!

[@codetothemoon]

thanks, really happy you liked it!

[@ItsGazareth]

This was great, I love how you gave actual examples for the things the compiler was complaining about.

[@codetothemoon]

Thanks Gazareth, glad you found it valuable!

[@Gemasted]

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.

[@codetothemoon]

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++...

[@gladoseus]

Very clear explanations and straight to the point. This the best 14 minutes of my rust journey so far.

[@codetothemoon]

thank you, glad you got something out of it!

[@ItzKernel]

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]

glad it was helpful, and thank you!

[@TheArgentan]

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

[@codetothemoon]

Thanks Pat, really happy this helped clear up the confusion around these concepts!

[@jrtomsic]

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.

[@codetothemoon]

nice, really happy you got something out of the video! 😎

[@richsadowsky8580]

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.

[@codetothemoon]

Thanks Rich, really happy you found it helpful!

[@NovaAquarius]

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

[@codetothemoon]

Thanks Nova, glad you found it valuable!

[@AndreCarneiro666]

So much effort to return a variable!

[@codetothemoon]

hah! luckily it's a bit of a corner case...

[@notengonickname]

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 !!!

[@codetothemoon]

Nice Jorge! Glad you found the video helpful!

[@dazealex]

I've watched many channels, but yours is by far the best explanation style I've seen so far! Kudos bro.

[@flippert0]

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 .

[@JanVotava]

Great video. You just made me to try clean my laptop screen with that grey line on your camera background 😅.

[@codetothemoon]

Thanks and hah! Green screen keying is tricky to get exactly right sometimes.... 🙃

[@Dygear]

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.

[@codetothemoon]

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.

[@kennystrawnmusic]

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

[@codetothemoon]

Good point, I think that is a potential approach too, if your program allows for it

[@kennystrawnmusic]

@@codetothemoon OS kernel is definitely something that does, so yes.

[@kocokan]

My golden rule: - borrowed value as fn params - return value

[@codetothemoon]

yep that's definitely a common scenario!

[@alexon2010]

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

[@codetothemoon]

It's a journey that can feel a bit slow at first but imo is well worth it!

[@eladmatia9953]

I think I finally understand lifetimes. Simple and elegant. Thank you!

[@codetothemoon]

Nice, glad you found the video helpful, thanks for watching!

[@alwin5995]

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

[@codetothemoon]

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.

[@TheBrazilRules]

This is so easy for people who worked with pointers before. Really says a lot about the state of programming nowadays

[@codetothemoon]

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

[@TheBrazilRules]

@@codetothemoon Maybe because you don't had anyone to explain it to you through examples?

[@voidemperor9372]

Magicccc!! we need more of these short videos. Great job :)

[@codetothemoon]

Thanks void, more to come!

[@el_carbonara]

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.

[@codetothemoon]

Nice, glad the example helped! I agree, it's really difficult to understand lifetimes without the context around how the function is actually invoked.

[@1Dr490n]

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👍

[@torppe2226]

Incredibly easy to understand and straight to the point video, keep up the good work!

[@codetothemoon]

Thanks, glad you found it valuable!

[@echobucket]

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.

[@codetothemoon]

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

[@introspecticon]

Great pacing and presentation - quickly becoming one of my favorite Rust channels

[@codetothemoon]

Thanks for the kind words! If there are any topics you'd like to see let me know!

[@introspecticon]

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

[@VishalPaudel-i6r]

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. ❤

[@Someone-q6f5x]

This channel is a blessing

[@codetothemoon]

Very happy to have you onboard!

[@torphedo6286]

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.

[@luiscarloscorderopena7030]

Excelent explanation!, really loved it! it's very concise and to the point

[@codetothemoon]

Thanks Luis, glad you found it valuable!

[@bitflogger]

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.

[@neunmalelf]

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.

[@AssemblyWizard]

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)

[@codetothemoon]

Great points - I'd love to go into lifetimes in more detail in a future video. Slices too!

[@hamdysaadpersonal]

Really it's a great video , keep going and we wand bigger projects 💙🔥

[@codetothemoon]

Thanks Hamdy! Bigger projects are on the way!

[@jeffg4686]

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.

[@jeffg4686]

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

[@jeffg4686]

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

[@codetothemoon]

Jeff - that's really cool - do you do modeling in Blender or do you use the Python APIs to make generative art?

[@codetothemoon]

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

[@jeffg4686]

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

[@mateusoliveira2776]

I would love a bigger video on this with a focus on examples! Great vid

[@codetothemoon]

Thanks, bigger examples are on the way!

[@jacoballen6099]

Killer video. Bet this guys channel blows up if he keeps making content in this style

[@codetothemoon]

Thanks Jacob, I hope you're right!

[@footballCartoon91]

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

[@llothar68]

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.

[@codetothemoon]

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.

[@HalfMonty11]

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

[@youpie]

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

[@sergiuoanes4635]

this really helped me a lot understanding these concepts. ...huge THANK YOU!!!

[@codetothemoon]

glad you found it valuable, thanks for watching!

[@BohdanTrotsenko]

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!

[@codetothemoon]

Thanks Bohdan! You have far more Rust LOCs under your belt than I, so your seal of approval is much appreciated!

[@icaroamorim3123]

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

[@codetothemoon]

hah, yeah those can get pretty hairy!

[@ziiirozone]

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 !

[@codetothemoon]

thanks ziii, glad you found it valuable!

[@aqua3418]

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

[@thanatosor]

These Rust features quickly turn themselves into a whole new class of puzzle for programmer to solve. Pretty good reason to leverage salary during interview. Else, just use LuaJIT.

[@codetothemoon]

Agree things can get tricky but compile time errors = way better than runtime errors

[@carrotstickz7290]

thanks for the clear and concise video!

[@codetothemoon]

Thanks Carrot! It'd be fair to attribute at least some of that clarity to your abundant levels of vitamin A!

[@oconnor663]

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

[@codetothemoon]

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

[@aussieexpat]

Coming from C++, there are some analogous patterns. But, it's nice to have the patterns enforced by the compiler.

[@headlibrarian1996]

He did grossly misrepresent the actual risk of memory issues in C++, something I find quite common coming from Rust devs. Aliasing and object lifetimes should be old hat for C++ devs.

[@havocthehobbit]

I use to fight with the rudy compiler more them cpp but now it's like the compiler is family and we only fight during the holidays.

[@codetothemoon]

LOL - love this analogy 😎

[@darrennew8211]

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.

[@codetothemoon]

Whoa I wasn't aware of Hermes, I stand corrected!

[@sbx1720]

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.

[@codetothemoon]

Thanks for watching! And good point, I probably should have done that

[@abraham7966]

I think I found my new favorite Rust channel.

[@codetothemoon]

Nice, very happy to have you onboard!

[@neoplumes]

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

[@codetothemoon]

Nice Neoplumes! Glad the video came in handy!

[@Omegka]

Great video. Really clear explanation.

[@codetothemoon]

Thanks, very happy you found it valuable!

[@АнтонМайоров-ж1л]

Thank you for your videos! Really want to watch video about traits and derive from you.

[@codetothemoon]

Glad you found them valuable! I'll put traits and derive on the video ideas list!

[@CharlesJacobs-n8y]

Thanks for simplifying the difficult parts!

[@codetothemoon]

glad you found it valuable!

[@upriser77]

Thank you so much! I've finally understood the lifetime.

[@codetothemoon]

Thanks for watching Chan, glad you found it valuable!

[@irlshrek]

I'd love a video on the intuitions that are useful revolving around implementing traits, rather than traits themselves!

[@codetothemoon]

Thanks, I'll put this on the video idea list!

[@littledmandan]

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]

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?

[@littledmandan]

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

[@hos7012]

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 😂

[@codetothemoon]

lol - I may have a keyboard video in the works that you may enjoy 😎

[@AbhishekBajpaiHere]

Loved it, thanks for the explanation

[@codetothemoon]

Thanks for watching Abishek!

[@EvGamerBETA]

Every time when people explain mutable references on yourube, the say that you can have only one mutable reference, but the example they give, is that you can't have immutable reference to the value, that has mutable references, which is a different thing to "having only one mutable reference"

[@codetothemoon]

can't remember exactly what I said in this one, but if i neglected to say you can only have one mutable reference at a time, that would have been an unintentional omission. Though it's also important to point out that no read-only references can be taken while a mutable reference is held 😎

[@cforster]

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

[@codetothemoon]

Thanks C Forester! C++ was my first language, and I think Rust is a very worthy successor.

[@takeiteasyeh]

most make-sense explanation of lifetimes i've seen.

[@codetothemoon]

fantastic, thank you! 😎

[@Kiwifruit00]

Thank you for this! I really love your content and would like to see more.

[@codetothemoon]

Thanks for watching, more is on the way!

[@KiranasOfRizon]

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.

[@codetothemoon]

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 KZbin 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).

[@KiranasOfRizon]

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

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?

[@KiranasOfRizon]

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

[@MsHofmannsJut]

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.

[@shyam2305]

Borrow checker couldn't have been demonstrated simpler !! subscribers + 1

[@codetothemoon]

Thanks, great to have you onboard!

[@dionysis_]

I really like the sound of the sped up keystrokes 🙂 Ok, I will now try to learn about Rust too..

[@codetothemoon]

Hah yeah when I first started speeding up the typing parts, my first instinct was to silence the audio, then I realized it sounds nice in a weird way...

[@_dinesh]

Excellent explanation!!! keep doing more videos like this!!

[@codetothemoon]

thanks, more to come!

[@danser_theplayer01]

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.

[@codetothemoon]

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

[@jackn]

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?

[@codetothemoon]

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

[@maxreuv]

Very well delivered and easy to follow! Thank you!

[@codetothemoon]

thanks maxreuv, glad you found it valuable!