The Rust Survival Guide

[@letsgetrusty]

📝Get your *FREE Rust cheat sheet* : letsgetrusty.com/cheatsheet

[@essentialG]

I know it took effort to create and all that stuff but come on, remove the registration bs and just make it free to download or just don’t at all.

[@lollol-se9ng]

​@@essentialGI support It doesn't look like it's free if you have to sign up.

[@DonutKop]

I can't get the PDF even if I put in my name and email lol

[@АртемФедоров-ю7б]

In the example with pushing an element to the vector you introduced a bug, when you put last element in the variable there was the last element of the vector before it was modified (not 4), but after you swap lines in the last there will be always 4. That's why when you fight with borrow checker you might introduce bugs in business logic. But in this case I believe unit tests are good option to fix that.

[@EmbeddedLearnr]

Any one figured how to handle this case ?

[@ficache]

​@@EmbeddedLearnr hello! I tested a little and the workaround I found is dereferencing with * symbol. like this let mut b = vec![0, 1, 3]; let n1 = *b.last().unwrap(); b.push(5); // Compiler doesn't throw error println!("{}", n1); The code works OK.

[@knicknacks]

​@@ficache this works in this case because the type is Copy. This is not a generic solution to this problem. A better solution would be to move b.push(4) to after the println macro

[@daemoncluster]

You just wrote unsafe code. Congrats. 😕

[@steamer2k319]

Finally a brief/quick explanation/example for lifetimes! Apparently, I've missed the part about the generic collapsing to the shortest duration among matching arguments each time I've tried to learn. That part of the vid could be its own clip/short. Using the colored vertical lines is a great way to visualize the lifetimes. You could also add inline color to the matching variable references.

[@MasterHigure]

The "longest of two strings" is the example from The Book, and everyone uses it, but very few explain what's actually going on. This video is no better in that regard. One video that does explain what's going on (or at least is honest about the fact that there is more going on, and tries to begin pulling on that string, because it's way too much to cover in 10 minutes), see "but what is lifetimes" by leddoo. For a more thorough introduction, Jon Gjengset has an hour and a half of "Crust of Rust: Lifetime Annotations".

[@steamer2k319]

@@MasterHigure Thanks for the pointers to some deeper dives. But yeah, what I appreciate about this video, is that it gets the gist across very concisely/quickly by leveraging animation/visualization.

[@erkintek]

So how to solve it?

[@forestcat512]

Ive never watched anything about rust or memory stuff in general but still understood most of the things you explained. I would say you did an amazing job at explaining it

[@mikhalpalych]

I have just wrote down these rules into anki cards after watching video from your rust playbook's course yesterday. I have repeated these cards already for like 3 times and i can say that starting learning rust through spaced repetition is greatest decision i made and i recommend this way for everybody

[@Sergio-ds3sq]

You explain stuff really well bro, thank you!!

[@DogeOfWar]

Really good teaching by example here. I feel like a lot of the time words themselves fail to illustrate concepts like this. Seeing how it works with actual code really cements it. Please keep making videos like this where you can demonstrate such concepts, thanks!

[@kevinmcfarlane2752]

I find with a lot of tech, I need to learn from a combination of reading, listening, watching and practicing. I pick up different things from each medium.

[@DogeOfWar]

@@kevinmcfarlane2752Totally agree, some things are easier to learn from theory than practice and vice versa.

[@StingSting844]

Tbh I got like 50% of it as I've never coded in rust. I hope this would be of great value when we start rust in our project next month

[@dragon-xt4vw]

Good luck!

[@nicklesseos]

Wow I can really tell the quality of your content has gone up. Bravo! Good job

[@indylawi5021]

Thank you for highlighting these Rust essentials in memory management as well as your clear explanation.

[@cheebadigga4092]

I tried it the last couple days and I practically fell in love with the language. rustc and rust-analyzer are incredible! And the language itself is amazing once the light bulb switches on in the back of your brain. I'm pumped :D Your channel is a gem by the way! Thanks!!

[@codeman99-dev]

6:20 Moving `x.push(4);` up a line changes the behavior. Can we instead move it below the print statement? Maybe wrap the let and println statements into their own scope?

[@steamer2k319]

...or clone/dereference the value of `last()` so that the value that we add to the local stack (variable reference) *is* the integer rather than a pointer into the heap.

[@yash1152]

7:15 yeah i was thinking same. thanks for mentioning it. this particular example shown in video is not practical, but i reckon that he was just focussing on the borrow validation.

[@codeman99-dev]

@@yash1152 it is pretty practical actually. It actually proves the rule is incorrect as stated. The actual compile error speaks in terms of time / location of usage.

[@IshCaudron]

This. Fixing a problem by writing the wrong business logic is not a good advice.

[@ficache]

hello for anyone wandering! I tested a little and the workaround I found is dereferencing with * symbol. like this let mut b = vec![0, 1, 3]; let n1 = *b.last().unwrap(); b.push(5); // Compiler doesn't throw error println!("{}", n1); But I'm a newbie, so idk is this good or bad. It just works :D

[@christianventes2553]

My problem with rust evangelist is when people say is not easy, and they inmeditialy start showing the incredible way rust is super optimal, wich is true but that doesn't alievate the learning curve. I love your survival guide because you really show us how is it done

[@meanmole3212]

The reason why Haskell failed compared to Rust is that the Haskell community's attitude towards people who complained about the complexity of the language was along the lines of "Maybe you are not smart enough for the language like we are? Too bad, because this language is superior to every other language once you understand it.". Rust took different approach and invested heavily in material that focused on making the language as easy to learn as possible through official language book / tutorial, in-code documentation code examples (for every standard library function you have instant access to not only the documentation of what the function does but how it is used with runnable code examples) and community efforts.

[@kevinmcfarlane2752]

@@meanmole3212Yes, imagine if Rust didn’t have that stuff. Many would just have moved on after the first hour.

[@ericbwertz]

@@meanmole3212 The century is still young -- Haskell still might catch on, but I'm hoping that something Lisp-y will get there first.

[@NicolaiSyvertsen]

Evangelists have already climbed the learning curve (or at least I hope so, though I know some who evangelize even when they barely know stuff themselves).

[@Vibrationofawesome]

Feel like I gotta watch this so many times. Rust is my first programming language I’m learning. I’m stubborn so I feel like I can do this!

[@grzegorzl4825]

Explained both simply and with details. Really good work!

[@zamokuhleshozi4494]

You need to make a course, well explained🙌🏽.

[@theultimateevil3430]

The problem with Garbage Collector is not always the runtime overhead, but inconsistent freezes up to a few milliseconds when it's doing the garbage collection. A program in Go will have spikes of cpu load whereas the same program in Rust will have slightly higher median load but more spread out and predictable.

[@JorgetePanete]

I think Java's Generational ZGC is interesting, it has sub-ms pauses

[@katazina0]

reason for the slightly higher median load?

[@theultimateevil3430]

​@@katazina0 allocations/deallocations are still there. Malloc and free are expensive, but if your memory load is predictable enough, you can reduce the malloc/free calls significantly. Custom allocators/arenas, object pools, ring buffers, small tricks like setting an optimal vector capacity, putting more on the stack instead of the heap, in-place algorithms to eliminate copying data. In some extreme cases (like when you develop a console game) you can malloc 10 gigs of RAM at the start and never deallocate it until the end, though calling your custom allocator is still work. Sometimes you can just not use heap at all (you can probably that with some microcontroller programs). All of this you can do with or without GC, some tricks require direct access to memory in a language, but some stuff like object pools is available everywhere.

[@datguy4104]

I'm already well into Go as a self taught programmer, likely even employable at this point. My only concern with Rust is the job market, are their even jobs for it? Everything else about it is great, even the way it manages memory is pretty straight forward.

[@aryanrahman3212]

Wow this was really well explained video of one of the central concepts of Rust!

[@leokim4943]

you are an amazing educator! i look forward to your Rust bootcamp 🦀

[@TimDrogin]

i studied rust for like 3 months, but now in the uni working on a c++ project i am unintentionaly doing everything rust style. Enums, optionals, etc

[@AadilValconi]

While it might not have been intentional this video does a great job convincing and explaining why Rust is so fast and memory efficient. also when I started learning programming Lifetimes is how I imagined a garbage collector worked but was shocked to learn most garbage collector eat up runtime to cleanup your memory. Rust seems like a fun language to learn.

[@ZachariahCavazos]

Wow.... incredible concise and informative. The line illustrations really helped. I feel like cracking back into rust for some longer running data processing I have to do. Thank you again, looking forward to smart pointers video!

[@bernoulli884]

Really clear and concise! Nice work.

[@Nonsense116]

Tbh I think ownership, borrowing, and lifetimes are the easiest topics to learn in rust just because there is SO MUCH content on these topics. If you were doing a memory management video I wish you would've gone into things like Box, Ref, ARef. There isn't a ton of content already out there

[@piguyalamode164]

11:04 another way to phrase this is that the lifetime annotations here tell the borrow checker that a and b must live at least as long as the returned value needs to live.

[@mikicerise6250]

Okay. But why wouldn't the compiler just assume this?

[@piguyalamode164]

​@@mikicerise6250 Rust already makes some assumptions for us. Rust could assume that all referenced inputs to a function(regardless of number) must live as long as the output. However, this has some tradeoffs. First it potentially creates weird borrow checker issues elsewhere(because now some values can't be modified for longer than would be expected and is necessary). And second it could have some performance impact by forcing rust to hold onto values for unnecessarily long periods of time. This just means the rust developers are unlikely to add this assumption unless they have good evidence that this constraint is the correct one in the vast majority of cases, which seems unlikely here. The rust devs have already added assumptions like this though. For example, a function that takes &self as a parameter and return a reference will (under conditions I've forgotten) assume &self must live as long as the returned reference by default.

[@mikicerise6250]

@@piguyalamode164 Mm. That makes sense, but, given this essentially turns control back over to the programmer, albeit by tweaking the proper compile-time checks on your references rather than properly handling your references in the runtime code, it does seem to bring us back 'round to 'skill issue' mistakes if it lets me make those references live shorter lives than the return reference, even though they might *be* the return reference. 😜 I get it though. I definitely want to try Rust for our next project. Even if you want to apply best practices, often you just inherit a mess. In our .Net codebase there is at least one place I've had to just stick a comment warning, 'whoever screws with this reference between here and here, screws us all.' 🤣 So even having a compiler that forces you to at least think about these things is nice, though I'm sure people can still find some way to write sloppy code haha. 😅

[@piguyalamode164]

@@mikicerise6250 I guess. Though with lifetimes the rust compiler is nice enough to catch any skill issues you make at compile time. The whole lifetime annotations thing is actually checked, which means code with too short lifetimes or invalid constraints won't compile, though this check is somewhat conservative(which is where you start needing unsafe code) and isn't currently designed to figure out what the "correct" lifetime should be, only that it is currently wrong

[@dukkcc2]

0:42 this is what I did and now I'm trying it again and I'm getting it by watching your videos

[@mushonnip]

new to rust, finally here I know what is

[@peter9477]

It's pretty typical to use 'a as a "throwaway" lifetime when you don't think it's important to give it a better name. Just habit in this case.

[@oleksiistri8429]

Could you make a video about most common pitfalls that newcomers fall into? I made same script on NodeJS, Bun and Rust and for some reason the one on Rust has the worst performance. Mostly I used: strings and &str, async functions, reading / writing files and actix-web framework. I understand what you described in this video, but still failed to get good performance

[@RichardWalterLanda]

a small rusty island of understanding in this youtube, thank yu, keep going!

[@monkeygame7]

I guess this is kind of nitpicky, but in the first example for explaining the borrow checker (7:10 ish) the code you change it to doesn't do the same thing as it did before you moved the push. Before resolving the borrow checker, it would print 3, but after you "fixed" it, it would print 4. I feel like it wrongly gives the impression that some things aren't "possible" in Rust when there is a way to do it, you just have to be explicit about how the memory is managed (e.g. use a box or something). But I get not wanting to over-complicate it; it probably would have been more accurate/good enough to just move the push after the print, which would maintain the same behavior. Great video nonetheless!

[@codeman99-dev]

Actually, you just need to move the push down, making it after the print statement. He stated the rule incorrectly. An immutable reference can exist here, but no mutations should happen before the use of the immutable reference. This is fine: fn main() { let mut x = vec![1, 2, 3]; let last = x.last().unwrap(); println!("{:?}", last); x.push(4); println!("{:?}", x); }

[@codeman99-dev]

In fact, the error speaks in terms of time / location of usage. It does not say "cannot make an immutable borrow". Ref: rustc --explain E0502

[@nmereginivincent5772]

This video is insightful. Thank you

[@DeclanMBrennan]

7:15 Maybe I've missed something. However, if you move the push() up one line, is this now not a different program that will print out 4 instead of 3?

[@liminal27]

6:33 just to clarify: the immutable borrow here is the last *element* of x eg. the &i32 which is returned by last - not x itself and then below that, the mutable borrow is &self which is x itself? Man I'm so confused...halp meeeeeee

[@BlueIsLeet]

0:10 explain how Kotlin gives you low level control but Java doesn't. I'll wait

[@HARUN-AKSU]

Which softwares do you use for creating videos?

[@ChrisPatti]

Great video! Thanks for making it! I was following everything perfectly until we got to the section on lifetimes. I felt like that was a bit rushed and included a bunch of information that wasn’t explained. that aside this is one of the best simplest explanations of ownership and borrowing in rust I’ve seen. Thank you!

[@OrbitalCookie]

Rust's borrow checker checks lifetimes one function at a time. The function signature contains everything necessary to know if there are borrowing mistakes in it. Without this understanding, borrow checker might seem as this complex system that traces lifetimes across modules. Nope. One function at a time. The function signature is the key to understanding lifetimes.

[@ronny332]

Especially the lifetimes section was bery helful, thank you!

[@bobschaaf2549]

"The Karen of all compilers". Priceless! You have a hot channel. Keep up the great work.

[@dakata2416]

Rust players when they stumble upon this video...

[@dragon-xt4vw]

lol

[@Another_El_User]

Now, they can become the Rust

[@smilebig3884]

🤣🤣🤣

[@morrsor]

I’d like to see more content like this. Big thumbs up 👍

[@danielmichalski2436]

You have earned my subscription, Sir. Great video; very well presented! ❤

[@obkf-too]

I wouldn't use Rust for everything, but it is complementary to my other languages (I mainly use Python since I am a Django web developer). However, I find that Rust is the least frustrating language to use (I don't trust google that much to use Go) for low level programming, and I really don't think it's hard, I has a different perspective, It's "Different" not hard, tho the syntax sucks (IMO).

[@remssi-dev]

Never used rust, but it seems super interesting

[@leshommesdupilly]

Karen rust compiler vs Chad cpp compiler: -Compile this bro. -Yes master. -> Segfault

[@soma_rc]

Thanks for the clear explanation. Will be pointing ppl here if they struggle.

[@hailuong9295]

well C# actually give you low level control compare to Kotlin, it has directly support safe pointer through Memory class, direct stack allocate through Span, and natively support struct too compare to non struct-ish in Kotlin. And it also has native SIMD support compare to Swift. And last thing you alway use raw pointer or do non GC memory manipulate through unsafe

[@metaltyphoon]

From all the languages showed, outside of C, C++ and Rust, C# is the one that gives you the lowest level control.

[@drsimons]

Dang, I'm pretty excited to start designing with ownership and borrowing but holy fuck that "lifetime" syntax is bizarre. Gonna need a strong drink before I start typing un-matched single quotes.

[@kurushimee]

The only languages I am proficient in are Python and C#, so trying to learn Rust is both exciting and intimidating

[@boliu5051]

great job! please continue this series.

[@torarinvik4920]

The borrow checker is a really smart solution or in general escape analysis. I think the next step would be to do something that Nim and perhaps Swift does. It moves values by default like in Swift but when it notices a shared value it reverts back to reference counting. This way you should get very good performance perhaps even optimal performance when they perfect this formula. In other words zero-overhead memory management. IMHO manual memory management is on life-support and will not be done in the future, how soon it will be a thing of the future I cannot predict. It might be 5 years, 10 years or even 15+ years.

[@theninjascientist689]

Rust tries to avoid doing things "by default" and instead relies on the programmer to tell it how to handle a situation. Explicit ".clone()"s, borrows and moves make it very easy to avoid memory bugs and work alongside other programmers who's brains you do not have access to.

[@torarinvik4920]

@@theninjascientist689 That is true. But the point I was trying to make was that the "relies on the programmer to tell it how to handle a situation" will eventually be a thing of the past. There was a time when handwriting assembly was the best solution because compilers were not yet good enough for optimal code. In the meantime, until automatic memory management becomes the norm, the borrow checker will be a vital tool in most system languages.

[@xdanic3]

I was looking at gdscript vs C# and one comment said reference counting is garbage collection, just another form of it, I wonder what could be argued against that.

[@torarinvik4920]

@@xdanic3 Yeah, garbage collectors AFAIK uses reference counting to track lifetimes. However, Swift uses something they call "automatic reference counting" ARC. I'm not sure exactly how it works, though, but they claim it's not a garbage collector.

[@IshCaudron]

Rule one of borrowing is wrong as the intended result of the not compiling version is not the same as the proposed solution. You introduce a bug in the code to satisfy the borroww checker.

[@bigice7184]

Your last example about the generic lifetimes was super confusing. I had to re-code it myself and had to replace " 'a " with " 'foo " to understand that " 'a " had nothing to do with parameter "a" . You just chose to use the same name for the lifetime specifier as one of the input parameters. Now I need to know how it works with multiple lifetime specifiers. Does the order dictate which lives the longest?! edit: code doesn't compile btw. Line 6 would need to be "result = longest(s1.as_str(), s2.as_str());"

[@BooleanIndecisive]

This is definitely a video about Rust. Yes indeed.

[@ALucaRD807]

The fact this video never mentioned reference counting drops its significance by a lot. "If you have objects that are used in multiple places and passed around, and you don't have refcounts, your code is almost certainly broken." (c) Linux documentation for krefs

[@dracodevil.]

Great video! We want more! Thanks!

[@ducksies]

Excellent explanations

[@MK-fw9qo]

Your channel is a gem bro thank you so much

[@rorysanchez]

Great explanation dude

[@Nick-tm2sw]

"general purpose, gives you low level control, is memory safe and is extremely performant" then proceeds to remove several languages that provide all of those that are not Rust. "Then there is only one obvious choice" is extremely subjective in that context. I really enjoy Rust but I also don't like to over sell it as the solution for everything. In the long run that is going to hurt the image of Rust, not help it.

[@ro0t3ntry]

This is it.. people just hop on the bandwagon and shout that it's the perfect language for everything when it is simply not. Those statements fooled me back when I was learning rust.

[@ahmadrezadorkhah9574]

Thanks i have better understanding of lifetime now

[@alrakssonson3095]

Thanks! Very cool format!

[@Sam-rb1id]

Rusts approach is not really unique. C++ had unique pointers since c++11 with the same kind of move semantics. And isn't a borrow pretty much just passing a const reference? I'm not an expert but I feel like Rust has largely streamlined some modern c++ concepts when it comes to safe memory management.

[@agailloty]

C# dev here, I really appreciate your channel. Rust is cool but sometimes the syntax is really cryptic. The lifetime 'a syntax is really disturbing and I wonder if there is any alternative to it ?

[@djasnive]

Waouh, Rust is so different from everything i've seen until now.

[@steamer2k319]

At 7:13, doesn't moving the call to last() after push() change the value of the `last` variable to 4 instead of 3?

[@henzosabiq]

Yup, it does change the behavior. If you want to add 4 to the list while still having `last` to evaluate to 3, move `x.push(4)` below the println. He gets the main point delivered, but code examples could be better.

[@PurpleLibRight]

Please create a Rust bootcamp.

[@alwaysahad]

Please..... @letsgetrusty

[@darukutsu]

Read rustbook

[@Etanmm]

He already did lmao

[@firefuegomakes]

I second this, from South Africa 🌍

[@omerdvir1709]

He did, 2 years ago

[@user-zn3zx6fk7u]

hey im curious, what video editor did you use? and how did you color the (code) text ?

[@krzysztofjuszczak906]

Honestly it sounds rather intuitive, simple even, when youre learning about it. then you try to actually do anything

[@kevinmcfarlane2752]

Yep. Exactly what I just said a couple of minutes ago! 😊 But you just have to keep plugging away. It’s satisfying when you get there.

[@krzysztofjuszczak906]

@kevinmcfarlane2752 is it really worth it tho? some of the most elegant, concise and clean code I've seen was written in rust. but the opposite is also true. if there's not an idiomatic way to do something, the code ends up looking really ugly and unsatisfying

[@alexanderneishkasha7903]

I can say that ownership concept is kind of easy to understand. The most difficult for me in rust are macros. Looks like something weird that shouldn't be in this language.

[@theninjascientist689]

Macros are indeed weird, but they're kind of already not in the language. Rust macros are code that writes Rust code. Most beginners shouldn't be reaching for macros as a tool to solve their problems.

[@edgeeffect]

Procedural Macros are one of the things that attracted me to Rust.

[@NicolaiSyvertsen]

Macros is unfortunately needed in order to simplify a lot of stuff that is incredibly tedious to write in pure rust. It is used extensively in language bindings. There is a reason people complain so much about boiler plate in C and or make ad-hoc code generators on a project by project basis. But it seems that Zig's comptime is a better way to do it.

[@theninjascientist689]

@@NicolaiSyvertsen Can you give me some examples of what you've had to write macros for? I'm curious

[@ora-ora-ora]

This video should be included in the official documentation

[@PoolWaterPiano]

WHat software do you use to mmake the code motion graphics in your videos?

[@luigitech3169]

Thanks, waiting for part2

[@91_isopropyl]

5:30 i borrow stuff all the time and take permanent possession. so idk what your talking about

[@taylors1545]

Zig is a strong contender, newer so not quite on par with Rust yet but it's getting there.

[@HereIsZane]

My main issue is I can't figure a side project to hone in all the fundamental stuff that isn't too complex

[@durza9390]

Clean explaination. Thx!

[@quasi_verum]

the next one that need to be discussed that not being mentioned => closure behavior over function, trait satisfying with derive.

[@mista_ia]

Great explanation. As newbie, 10:42 when defining lifetimes, did you choose to name it by character "a", is it rust convention, or is it related to the function parameter a ?

[@jcm2606]

General convention I've seen is to try to pick a name that makes sense for what the lifetime represents (ie if you have a "DbManager" struct that holds some objects and you take a reference to that object, it'd be wise to use 'db or 'mgr as the lifetime name so that you can more easily tell what the lifetime represents), and if there isn't a good name, just go through the alphabet.

[@user-uu4nm6fc5o]

the fix for Rule 1 is not straightforward. the original program was intended to print 3, and the fix prints 4.

[@letronix6243]

yes

[@SirSomnolent]

My dude this was super helpful thanks

[@yakovlev_io]

Great explanation, thank you

[@GrenYT]

Is it not possible to lie to the compiler and cause memory errors with the generic lifetimes bit? Feels like it could be possible....

[@weightlifter1377]

Is it good to be interested in Zig also and should one learn it

[@dragon-xt4vw]

Probably, if you're interested. If you don't have a specific need for it, that's the only good reason.

[@seasong7655]

Anyone noticed how the compiler will give a lifetime annotation error even when there's not inner scope? Also the compiler didn't see s1 is always returned. There was no need to even annotate the lifetimes, but the compiler still made you do it

[@ericbwertz]

An inner scope is only one way that this can happen -- any transfer of ownership will cause this to happen. It IS the case that the compiler could figure out some of these lifetime contentions, but not all of us have that much time.

[@0xd3c0d3d]

10:36 These are the things that make me increasingly certain that it was a great choice to have migrated to Zig in the last 2 months.

[@chaqua1559]

For me zig is harder than Rust

[@0xd3c0d3d]

@@chaqua1559 Zig can be more difficult for some people due to not having as much documentation compared to Rust and still very few people producing content about it, and when you have a more complex issue you have to turn to the community to help you resolve it, but this is a scenario that will change as time goes by, everything is still being built.

[@0xd3c0d3d]

@@chaqua1559 In my case, I'm very happy with Zig, something that didn't happen when I programmed in Rust, I always got bored. This is something you realize over time, you also start to ask yourself: do I really need all these **advanced** and **innovative** features that Rust has? which always stops me from doing things unless I use strict rules, you will eventually realize that simple memory management mechanisms like Zig with reasonable security is what you really need in most cases.

[@fu3x11]

ngl, all we really need to know is how to learn rust libraries, it gets confusing like i tried learning yew and bevy, but i failed. i only kinda learned the windows-rs crate

[@CYXXYC]

if you have any questions about yew, we will hear you out in the yew discord

[@fu3x11]

@@CYXXYC that's not the point

[@diadetediotedio6918]

To use libraries of any language you need to first know the language, and the library should have a good documentation. Did you read bevy documentation and have a good understanding of the language?

[@fu3x11]

@@diadetediotedio6918 i know the language very well, just stuff got weird documentation

[@kamertonaudiophileplayer847]

Thanks for keeping Rust alive. I noticed that an interest to Rust dropped recent time. Finding a Rust job becomes more complex and time consuming.

[@psykespb9532]

Lifetimes are annotated with single quotes, not ticks. > Unicode character '`' (Grave Accent) looks like ''' (Single Quote), but it is not

[@danielgrayling5032]

Great explanation, thanks.

[@charlesstepp129]

This is a good reference vid.

[@bread8176]

I see you removed C# when you said "give you low level control." Maybe it's worth giving the language another look, you might be surprised.

[@joergw]

Thanks. That was easy to understand 😊

[@daniilgavrilikhin34]

It should be “The Rust Survival Book”

[@edgeeffect]

Paul Atreides: "They tried... and failed?" Gaius Helen Mohiam: "They tried and DIED!"

[@daemon_zero]

Appearently for Rust devs, modern C++ doesn't exist. "Garbage collector or manual memory allocation"... how about smart pointers?

[@sergiuoanes4635]

Excellent video! Thanks

[@putzz67767]

Linda explicação!! Parabéns pela didática!!

[@harikrishnanb7273]

need a follow-up video!!

[@ramprasadpoudel8170]

more video of lifetimes please, especially its annotation in struct