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

1:28 For mistake #2, there is a common mistake within it: *Overusing vectors* . A lot of times, beginners will prefer creating vectors whenever they need an arbitrary amount of things. This is indeed what vectors are for, _when they are useful_ . Vectors are relatively costly and are meant for _storing_ data in a longer timespan. If you are collecting data into a vector just to perform operations on the vector and then no longer need it thereafter, then you are doing it wrong. The fix here is to not use a vector at all. In your minimal example, the full scale is not seen, so what you did _might_ have been necessary, but if you just wanted to use the new vector to do something with each element and then discard the vector, then all you needed to do is for-loop through the same iterator but without the `collect` method, which avoids creating a vector. If instead you do need a vector because some other function requires it or for some other reason, then you should look into why you have a vector in the first place. There would be no need to have a vector twice in your code if one vector transforms into the other. The fix in this case is to look for how to avoid creating the first vector, and just using an iterator like in my previous fix to collect into the desired vector directly. If you got the first vector from a function, then shame on that function; it should have returned an iterator instead of allocating a vector. If you created that function, then here's what you can do to fix the return type: Allocating and returning a vector from a function is often undesirable because you are forcing an allocation which the user might not need. Instead, return an iterator without using `collect`, which avoids creating a vector. The returned type signature will look like this: `impl Iterator` (change `i32` to whatever type of element the iterator is iterating through.) This is called an "opaque type", which hides the often complex full type signature that you are actually returning, and only exposes what relevant trait you are trying to provide. (If you returned the true iterator type instead of a vector, it would look a lot more confusing, or it might not even be possible.) For more information on opaque types, here's the official reference: doc.rust-lang.org/reference/types/impl-trait.html

3:15 when just returning true/false from match arms, it can be written even more concise using the matches! macro: fn can_publish_blog(role: Role) -> bool { matches!(role, Role::Admin | Role::Writer) }

Common mistake number 0: Waiting too long to start learning Rust.

Naturally the advanced error is object oriented mutability, with the incorrect solution being to slop more mutability onto the code until it complies and the correct way being to just make it more functional with better separation of concerns

If you're going to turn warnings into errors in CI, you should also pin the Rust toolchain version used, otherwise new warnings can be added in any minor version (especially in Clippy). Almost all of my projects hit a new clippy finding after every couple of Rust updates, if they hard-blocked CI then it would be a huge nuisance. Fun fact: You can get out ahead of some of these checks by installing the nightly toolchain and running cargo +nightly clippy --all-targets. It's like those "new lint from the future just leaked" memes except real.

The community needs more of these friendly newbie resources! Keep it up!

The last one is extremely helpful. It's often hard to wrap up my mind around this inability of porting code line by line.

I wrote an interpreter as my first project in Rust, and I encountered that last problem exactly. I had closures that would have a reference to the enclosing scope, and the borrow checker was very upset with me. I tried to fix it using lifetime annotations, but I quickly got way too confused. I managed to get it to work by slapping Rc and RefCell on things, but it felt really wrong. Thanks for sharing ideas about how to avoid these types of issues in the future!

Love mistake 6 as I did this and didn't use some of the amazing built-in traits. One I recommend looking at is the `Display` trait to customise the output of a println! or format! marcos.

Nice video! However, I disagree with its thumbnail. There's nothing bad with `Rc` on its own, thumbnail is misleading. I'd instead put for loop with i += 1 and array indexing, a more common "mistake" due to poor knowledge of the lang.

11:05 monsters could be better-defined as: “let mut monsters = vec![Monster::default(); 5];”

Thanks for your video. Especially your last, more advanced subject of the monsters game with the stored and shared closure references. I like that example also from the aspect of functional programming, in which the lack of state is an important aspect. Having everything directly exchanged between functions, including those closures which you don't store anymore, makes your program more functional kind and less of the imperative style coding kind. This is nice. I would also like to mention that I see multiple points in which the The Book can still improve here.

awesome video! I've been reflected myself in much of the topics you have covered, and many others I've already fixed them. hanks for your work!

Most of these were pretty avoidable when I started learning rust. Maybe it's because I came from a functional programming background; understanding the value of enums, results and option, using map, filter, reduce etc. Now that being said, the biggest issue I had with rust when I first started is that I treated it like a functional language. Rust is first and foremost a procedural and imperative language with functional features. If you try to treat it as a purely functional language you're going to be in for a lot of pain. I can't tell you how often I bounced off the borrow checker because of this. Anyway, good video; all this is really good advice and it's hard to remember that this stuff is not obvious when you've been using the language for 8 years.

keep up the fantastic rust videos. they are always helpful and very intresting. one of the reasons why i love rust

Awesome content as usual! Thanks for sharing those mistakes!

Very helpful! Rust by example is amazing at the start. Then these problem example & improvement versions help a lot to for deeper understanding. These are a little harder to come by, thanks for the work! Maybe one idea for future videos: Have you thought about displaying the base and improved versions side by side? I found myself rewinding several times at each topic. Its probably bad for visibility while watching on a smartphone, but maybe there is a way add it in after every example 2 seconds just to pause and read or something like that..

I also don't always implement the error trait on my error types. I tried to get around proper error handling for some time. But this error derive crate seems helpful. I might start using it.

The most fundamental one is the last one, on the mutability. Unfortunately it can not to be learned so easily, one should pass thru functional programming at first, I think.

@ 3:30 don’t forget the relatively new let else statement which can be used for guarding clauses. It is similar to if let but always assigns, unless you call return in the else block.

You know, it would be really helpful to have a video expounding on each of these points, as it was hard to understand exactly what I need to learn/change in my programming from such short examples - however, it was also apparent from the examples that there are nuances I'm missing with my Rust programming.

Was not aware of the array_windows and windows methods on arrays. Might start using this more often... although right now, array_windows is only in nightly, so the windows method may be preferable.

Informative video - as usual! 👍

I'm new to rust and this video help a ton, especially the end when you used game logic to explain things

Excellent advice for beginners like me.

Mistake 2: overusing slice indexing 6:37: Making actual mistake when using slice indexing

I like the javascript to rust example, it made things more easier to understand. Could you do more of them if most people find it useful :) its sure as hell useful to me.

array_windows() is nightly... I highly discourage usage of nightly. Especially in videos directed to newbies.

Good and helpful as always.

A mistake that I want to make a lot is creating a variable without a value, then going into a loop and assigning the value of the variable inside the loop. Finally, trying to use the variable after the loop causes some sort of lifetime error.

A note on mistake 2. When I tried to use the array_windows method I get "error[E0658]: use of unstable library feature 'array_windows'". After some researching array_windows is currently an experimental feature and only available for rust Nightly. Therefore, I think that it is a bit irresponsible to claim that not using it is a mistake. As of writing I have 1.66.1 installed while the latest official release is 1.67.0 and array_windows is experimental in both. Otherwise I think you made a good video, with nice examples.

Thanks for the video, I liked it and there are some changes I will try to focus on in the future. I’ve been using Rust for a while now and my feedback for this video would be that it was too fast paced. I think a beginner would need more verbose explanations for each of the common mistakes… maybe next time you could highlight each change that was made in you editor?

I am trying to learn Rust. I have c/c++ background. But I havent used them for a long time. My initial impression is, rust looks extremely sophisticated. To start writing actual code, I found my self to learn a lot of rules and coding techniques. It is definetely not an ordinary language at all. But I am not thinking to give up. I want to build a command line tool. Lets see how it will go :)

One fatal mistake most make is not using Rust.

Вот это то, что надо! Вроде бы базовые вещи, но такие важные и нужные.

Thanks, super useful

Might want to note that many of the underused standard library traits mentioned in Mistake 6 are technically core library traits that the standard library depends on - which means “#![no_std]” (i.e. kernel) developers like myself don’t have an excuse either.

Amazing video, congrats!

4:59 I should have known about Default, its so useful.

TBH I had a lot of pain exactly when was struggling with a bad ownership model in my project

Very nice and interesting video! One point i found no video at all to is how to write a plugin for nushell. Since nu scripts will be compilable one day, it could be very powerful to be able to write integrations in Rust with more functions.

Now this video is very useful. Cheers

this is awesome, thanks

I didn't know about array_windows, so thank you for that tip!

I loved the Rc/RefCell explanation

Help a lot👍🏻

Thx very much 💖

For the example of array_windows, are you sure the revised code is more efficient than the one using index?

Why is pattern matching better than an if statement when checking for a boolean state? (Is_some)

10:55 small detail but it might be worth using available syntactic sugar given the target audience of the video. So in this case adding a Clone derive to Monster, which allows for ```rs let mut monsters = vec![Monster::default(); 5]; ```

This video was worth watching for the todo! macro alone. I've wasted so much time commenting out return values of functions since the rust analyzer would complain

What opinions do you have on the typenum crate and similar? If I want compile time constraints on a string or number without sacrificing readability is it good?

Great tips, thanks.

one common mistake I made when I started with rust was to overuse copy

I think the code structure at the end is odd. Closures should avoid capturing things if possible, and should be more purely functional. Capturing mutable state is an indication of side effects. I would say here, the damage counter should borrow the monsters, iterate over them, and mutate itself.

Excelent tips!

I just have a question related to Smart Pointers. Are there some best practices about when to use Smart Pointers? Thank you a lot for your content. Congrats once more

Do you have a linter setup for this?

In my case, I am using too much unsafe code to deal with pointers, interior mutability u.u Thanks for the video

While I agree that excessive usage of `Rc` is a sign of bad design you would really need to work hard to cause a deadlock. And there is no decrease in memory safety. Unless you touch `unsafe`, your code **will** be memory safe.

Sorry, I have a question: In the Bonus section, last slide, the counter.on_damaged_received is called. But it was removed in the 2nd approach in impl Monster. How does this work? Btw.: This video helps me a lot!

I'm struggling a bit to fully understand the last one. I agree the smart pointer stuff seems complex and risky, but I don't quite follow what is being suggested for the alternative.

There's no way that CI works, right? There's no cargo installed in the base actions/checkout image?

2:19 why you return int (32bit signed integer) but array length is size_t (64bit unsigned int)

Wow I did not know most of those cool features!

6:28 that parsing code will panic if passed "(1,2,3)"? Seems like an example that teaches bad habits?

Damn, that's the first use of the "windows" method I've seen. Good job.

Array_windows docs have example like this: let iter = slice.array_windows::(); I'm assuming that's incorrect... 2 isn't a type...

I am so happy to say that Michael Bryan is my mentor.

The last "error" is actually the reason I decided not to keep messing with Rust and went back to C++, C# and other languages.

In mistake number 6 you did what you preached not to, and indexed into an array whithout checking if it was even empty.

4:45 What library?

Deadlocks with Rc?

What theme is that ?

I don't know. I am learning Rust not too much. But the last example seems like Rust memory safe but overcomplicated. (My main work is Typescript developer 5 years)

Very interesting the last part of the game

why not just return the damage? this method call is synced, no need for a callback 13:15. and no extra struct in 13:32, what do you think?

Huuuuuuuge! Congrats for that video! Really useful! 🎉🎉

Common mistake number -1 Not bothering to read the docs

Unwrapping options is the bane of my existence

great video

Can anyone recommend a good book on Rust that explains basic concepts for a beginner?

functional programming approach reduce chances of using smart pointer

Can someone explain how the first example is unnecessary indirection?

Hi. First I would like to tell you that, I love your videos, are super educational and I really learn a lot with all of it. Thank you for share you knowlodge. I have a question. I am looking for a emulator or something that show me the status of the heap and the stack while I debug the code. DO you know some tool or extension like this?

I love how he gives instructions with the assumption that vscode is the only way to type rust code

So I asked if you have a linter setup for this and got no responses...I am guessing the reason is because it's too difficult to do. But why is it too difficult? Can't we use AI to detect all kinds of this class of problems and even more obfuscated/spread out/deeper ones? There's an issue of "Do we even have enough free time to make an AI linter that can do this? No. It's not worth the time it takes to figure out how warn against everything a coder should know how not to do on their own." But maybe that's invalid ...

The unfortunateness of this video is that those who made the deadly mistakes aren't with us anymore, so they can't learn from the video.

2:15 I wouldn't say, it's always bad to use zero as a special value, though. I still do that in one of my programs. But I get why it's not considered good practice.

The mistakes experienced rust developers make would be interesting

You say 1:45 is the improved version. Is the goal not readable code? People make "Mistake 2" and will continue to make it because its about making it readable. Getting on your podium and stating its a deadly mistake makes developing Rust code harder for beginner developers. They are going to use each and every Rust feature when the necessity is not there, bloating their code. Why wasn't mistake 2 corrected by showing a guarantee that the vector won't be improperly accessed, or having a method for dealing with that scenario? Rust can solve this issue in a simpler way. An actual deadly mistake is including several hundred unnecessary /unclear dependencies then uploading the project. If we want a public standard for proper code and coding techniques, why are we not just following the ones that exist already? The ones that emphasize readability (for newer developers, for team projects, for ease of mind retainability), efficiency (no need to waste resources checking the index of an array in a for loop, that can be the compiler's job), safety, portability, etc. Mistake 2's correction is counterintuitive at worst and confusing at best. It has no place being considered "correct" or "preferred"

You should includes matches macro.

Дякую!

I am about to start reading the smart pointers chapter (ch 15) in the book. I actually hesitated a bit before clicking on this video because it looked difficult. Glad I watched this anyway.

Reductive coding supports less dependencies, in less languages, on unsupported devices.

"If you are not careful, your code can cause deadlocks and crashes" - NOT QUITE CORRECT. Deadlocks yes. But a 'crash' is usually some kind of undefined behavior. And although it can deadlock, Rust programs can **not** contain undefined behaviour as long as we don't use "unsafe".

hey that looks like my code fr

Mistake #4 is inside the code for mistake #6… 🎉

Most of these mistakes are not specific to Rust!