8 deadly mistakes beginner Rust developers make
Vložit
- čas přidán 25. 06. 2024
- New Rustaceans are an inquisitive bunch and want to dive into the language head first, but sometimes this leads to some common mistakes that beginners make. Today I am going to discuss 8 common mistakes that are made by new Rust developers or even more experienced Rust developers alike.
Michael's Blog Post: adventures.michaelfbryan.com/...
FREE Rust Cheat Sheet: letsgetrusty.com/cheatsheet
Chapters:
0:00 Intro
0:32 Mistake 1
1:11 Mistake 2
1:55 Mistake 3
2:40 Mistake 4
3:37 Mistake 5
4:50 Mistake 6
6:47 Mistake 7
7:48 Mistake 8
9:05 Bonus - Věda a technologie
📝Get your *FREE Rust cheat sheet* :
www.letsgetrusty.com/cheatsheet
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)
}
If I'm not mistaken, clippy would even point this out :)
Cool
I was honestly baffled that an expression that could just've been `role == "Admin" || role == "Writer"` was made into what basically amounts to a `if { true } else { false }` kind of setup.
@@AlexanderKrivacsSchrder All humans suffer from this, lol.
Instead of matches it would be better to exhaustively match on the enum to ensure not forgetting to handle new variants.
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
example?
That's interesting. You can do that in Rust?
Said above in a nutshell: if you have **a lot of short** vectors and you need to perform operations on each item of each vec but without creating a resulting vec, it *might* be better to turn vectors into so called "adaptor iterators" without consuming them (*via .collect()*) and then iterate over resulted iterators using regular for loop (under the hood for loop calls .next() method of iterators).
But there is a better (more concise) way for same result, it's done via .into_iter() method (*instead of .iter()*): myvec.into_iter().map(...).for_each(...);
Anyway, if you are beginnner, relax and use vectors. And in order to handle more gracefully such specific cases as described put into your todo list reading (and comprehending) chapter about iterators in rust.
Even if you *do* need a container, you don't always need a vector. You can collect() into a boxed slice, which is a fixed-size allocation that doesn't need to bother with the full complexity of Vec. The only reason to collect() into a Vec is if you're going to add or remove elements later. Vec also supplies an into_boxed_slice() convenience method for cases where you don't have an intermediate iterator.
Common mistake number 0: Waiting too long to start learning Rust.
And its close cousin: giving up too quickly without working through the initial hard part of learning Rust where you’re constantly battling the borrow checker.
The real mistake is learning Rust at all. If you're a frontend developer learn javascript. For everything else there's Python.
@@alessandrorossi1294 I disagree. Python was my main language for over a decade. And i started Rust because it complements Python very good. I use Python or Rust for whatever the situation needs to. And for simple things I can use Bash (shell scripting).
@@alessandrorossi1294 python only works when you don’t need performance, and telling that it works already means tolerating a lot of defaults. I used to program only in python and after learning rust I always miss the type system, the errors messages and the overall safety of rust. You should really try learning rust, it’s coming for the web as well.
@@alessandrorossi1294 Languages are usually designed for a specific set of problems. Of course you can write a website front end in C++ or make JS code run on a microcontroller, but it doesn't mean that that's a good idea. Python has its place, it's a good language, especially for small stuff, purely scientific stuff, or stuff that is needed fast and not necessarily rock solid. But there is a lot of stuff apart from frontend that python should just never be used for.
As a programmer with experience in a bunch of different fields, very rarely can learning a new technology be a mistake. Even a shitty technology can provide useful insight, and any learning process at all provides some useful mental exersize, to keep you flexible enough to be able to solve problems well and fast.
Rust approaches memory safety and compile time error checking in quite a unique and novel way, that it's worth learning even just for the sake of knowing, that those kinds of things can be approached this way.
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
Using Rust for almost purely functional code is considerably easy whereas using it for almost purely object-oriented code is a huge pain in the ass.
@@stevenhe3462 absolutely, but even better is even though the improved code here isn't fully functional, the mutable objects that it does have are mutable in a way that you can trust.
If the refcell is encapsulated so that only one struct has control over the interior meaning mutability then most of the concerns about safety go away, at a slight cost to performance. Telling people the solution is to restructure their entire API and structure (which is the suggested solution) is a huge cost.
@@calder-ty sure, but hopefully this provides an insight so that the code isn't built that way in the first place
Especially since it's the compiler complaining about it, rather than some obscure bug in production
@@calder-ty That is why we should better do it that way in the first place. Having object oriented mutability contributes greatly to the complexity to refactor code. And, mutability itself introduces high difficulty to parallelize the execution.
The last one is extremely helpful. It's often hard to wrap up my mind around this inability of porting code line by line.
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!
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.
Rust has opened up my eyes to the dangers of inner mutibility -- and holding references to other objects in general. I have had to unlearn some seriously bad habits I picked up from languages where this is easy.
11:05 monsters could be better-defined as:
“let mut monsters = vec![Monster::default(); 5];”
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.
My first program in Rust was a parser for my own programming language, and used multiple levels of Rc as from a tutorial, and after a while I was getting stuck and confused on these borrows, so I realized why do I go through so much to avoid receiving self as a mutable reference when I can just accept self as a mutable reference. And I did. And my code became 2-3 times shorter and I never had a single issue I was stuck on. To be honest, I'm not sure what else would one use Rc/RefCell, it was my only encounter with it.
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.
One fatal mistake most make is not using Rust.
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.
Mistake 2: overusing slice indexing
6:37: Making actual mistake when using slice indexing
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.
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.
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.
keep up the fantastic rust videos. they are always helpful and very intresting. one of the reasons why i love rust
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.
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!
@ 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.
Excellent advice for beginners like me.
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.
I'm new to rust and this video help a ton, especially the end when you used game logic to explain things
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.
4:59 I should have known about Default, its so useful.
one common mistake I made when I started with rust was to overuse copy
Awesome content as usual! Thanks for sharing those mistakes!
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.
array_windows() is nightly... I highly discourage usage of nightly. Especially in videos directed to newbies.
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.
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..
The last "error" is actually the reason I decided not to keep messing with Rust and went back to C++, C# and other languages.
Right, the life is way more fun squashing bugs, properly designed software is boring.
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 :)
Вот это то, что надо! Вроде бы базовые вещи, но такие важные и нужные.
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.
Informative video - as usual! 👍
I didn't know about array_windows, so thank you for that tip!
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];
```
I loved the Rc/RefCell explanation
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
I am so happy to say that Michael Bryan is my mentor.
TBH I had a lot of pain exactly when was struggling with a bad ownership model in my project
Good and helpful as always.
Amazing video, congrats!
Now this video is very useful. Cheers
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.
`windows` on its own should be used instead of `array_windows` if you want to avoid unstable features. They're basically the same, except one takes a size parameter at compile time and gives fixed-length arrays, while the other takes a size parameter at runtime and gives slices that it promises are all with the right size. As you can see from my description, it's pretty clear which I think is better, but the reason it's unstable is because of its use of const-generics, so it wasn't possible to implement for much of Rust's life.
Common mistake number -1 Not bothering to read the docs
Thanks, super useful
Great tips, thanks.
Unwrapping options is the bane of my existence
Wow I did not know most of those cool features!
Help a lot👍🏻
Damn, that's the first use of the "windows" method I've seen. Good job.
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.
For the example of array_windows, are you sure the revised code is more efficient than the one using index?
this is awesome, thanks
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?
Being in this same situation, I expected to not grok all of this now, but would feel "that tingle" when I got to the language parts that I haven't run into yet. The thumbnail nearly scared me off, but I consciously decided that it wasn't for me, but instead for my future &self.
Do you have a linter setup for this?
Thx very much 💖
In my case, I am using too much unsafe code to deal with pointers, interior mutability u.u
Thanks for the video
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?
I'm sure there still are circumstances where it's useful, but a lot of what's advertised can be done with const generics now.
struct Foo {
data: [i32; N]
}
Most of these mistakes are not specific to Rust!
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 love how he gives instructions with the assumption that vscode is the only way to type rust code
What here suggested that? Perhaps only the continuous integration thing but that is doable in many other ways.
Very interesting the last part of the game
2:19 why you return int (32bit signed integer) but array length is size_t (64bit unsigned int)
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.
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.
passing around data instead of closures containing references to objects whose lifetime you can hardly keep track of
i am confused too.
1. why the DamageCounter needs to be updated separately and it is not enough to do all the calculations in .take_damage() is not explained,
2. why do there need to be many damage callbacks requiring the Box> is not explained, as a single callback field could be stored inside the struct with generics and no allocation with Box would be necessary
3. DamageCounter could wrap the damage in a Cell, and then use (&self) method signatures
4:45 What library?
The mistakes experienced rust developers make would be interesting
What theme is that ?
There's no way that CI works, right? There's no cargo installed in the base actions/checkout image?
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
In data types (eg structs) use the cheapest that works, as a rule of thumb: T before Box before Rc before Arc. Basically never use &T in data types unless you know what you're doing. For transient references like parameters and local vars you should nearly always use just &T unless you have a reason to use something else.
Very generally, there's little cause to use Rc in most well designed code, Arc is mostly for fiddly mutithreaded internals, so really you are mostly choosing between T and Box. The main thing Box gives you is that you don't need to worry about the size of T while still having ownership, so it's for things like preventing infinite size types in trees, making it cheaper to pass around big types, and enabling dynamic types (Box).
@@SimonBuchanNz wow! I appreciate your response! Thank you a lot!
Deadlocks with Rc?
I was also thinking that.🤔
And a close cousin: not using Weak and creating cyclic references that never get cleaned up.
Yeah, how is that possible? Rc allows us to have multiple owners, but we still have to follow the 3 prime borrowing rules. Dead locks in Rust, is that even possible?
@@TON-vz3pe you can deadlock a rwlock, but refcell just panics if the borrow rules are violated
In mistake number 6 you did what you preached not to, and indexed into an array whithout checking if it was even empty.
Huuuuuuuge! Congrats for that video! Really useful! 🎉🎉
Why is pattern matching better than an if statement when checking for a boolean state? (Is_some)
6:28 that parsing code will panic if passed "(1,2,3)"? Seems like an example that teaches bad habits?
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)
Array_windows docs have example like this:
let iter = slice.array_windows::();
I'm assuming that's incorrect... 2 isn't a type...
great video
Reductive coding supports less dependencies, in less languages, on unsupported devices.
Always remember: A struct is not an object.
"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".
functional programming approach reduce chances of using smart pointer
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?
That would be the same idea as using an "AttackSummary", just skipping the struct. If you only need one metric, then returning only a number works fine.
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 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.
hey that looks like my code fr
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"
Can anyone recommend a good book on Rust that explains basic concepts for a beginner?
Nothing better than it's official documentation. It's so concise and has a straightforward vocabulary, increasing for that reason the ease of understanding the concepts you need to dive into. Indeed, I recommend you to have a strong programming background to be able to actually understand what you're reading, and of course, learning about Rust and its ecosystem.
@@BryanBaron55 Yeah definitely, the Rust Book is an absolutely awesome resource
Can someone explain how the first example is unnecessary indirection?
String is an owned type stored on the heap, basically it's an indirection layer for &str. In this case you do not need to store on the heap when you have a static alternative which is way more performant. And you get both string types supported because Rust automatically infers &str from String and also accepts &str.
It's true, I knew a guy who didn't use the FromStr trait and instead defined their own from_str function on a type. They died the next day. These mistakes are _deadly_.
I think I've done all of them...
6:08 It's worth noting that `thiserror` allows you to easily implement `From` by annotating with `#[from]`