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) }
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.
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
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.
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
@@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.
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.
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!
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.
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.
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.
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.
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.
@ 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.
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.
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.
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.
@@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.
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.
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.
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 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.
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.
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.
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
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.
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.
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]; ```
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 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.
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.
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.
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
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)
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).
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.
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.
"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".
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?
As per the language reference book, "GenericParam" may be any of "lifetime", "type" or "const". Const generic parameters allows you to avoid things like "vec2","vec3","vec4" you find in e.g. the OpenGL math library by just having a generic vec and defining it automatically each time it's invoked with a new constant in the code.
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!
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.
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_.
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.
@@ДавидПлеван Why do you think, I'm talking about error integers? I think, I basically had an index, but 0 did represent some default elemen, while 1 represented element 0 of an array.
@@porky1118 By returning some hard coded default value you cannot know if a function failed or not. I think by default your should use option, but if you need an infallible version, create a separate function like search_or(default: usize) -> usize.
9:00 I consider myself to be a experienced Rust programmer, I'm using Rust for 5 years maybe, but I still do or recently did some of the "beginner" mistakes. For example I didn't use clippy until maybe half a year ago.
But not using Rc and structuring programs differently is one of the first things I learned when using Rust. Probably after a year or so. I guess, that's because I think, I'm smarter than everyone, and therefore ignore advice from other people and only look things up things, when I don't find solutions myself. So I only learn, what's really necessary/useful from experience. And using Rc is just annoying to work with, so I had to find a way to work around it.
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 ...
I think most of these simply go beyond a linter and go more into code generation territory: You need to understand the greater context to make a decision. Even something as simple as &String vs. &str depends on the context. But if an AI system understands the greater context, why not have it generate the code in the first place instead of just pointing out when you make mistakes? Things certainly seem to move in that direction... Also, there are already clippy flags that check for some of these. For example clippy::new-without-default will trigger when you have a Something::new() not taking parameters but don't implement Default.
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.
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] }
📝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.
❤ TT tu 😂❤e
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.
The community needs more of these friendly newbie resources! Keep it up!
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.
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!
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.
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.
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.
11:05 monsters could be better-defined as:
“let mut monsters = vec![Monster::default(); 5];”
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
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.
@ 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.
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.
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.
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.
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.
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.
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 :)
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.
Вот это то, что надо! Вроде бы базовые вещи, но такие важные и нужные.
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.
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.
one common mistake I made when I started with rust was to overuse copy
One fatal mistake most make is not using Rust.
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 loved the Rc/RefCell explanation
keep up the fantastic rust videos. they are always helpful and very intresting. one of the reasons why i love rust
Excellent advice for beginners like me.
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.
TBH I had a lot of pain exactly when was struggling with a bad ownership model in my project
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.
4:59 I should have known about Default, its so useful.
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.
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];
```
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 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.
Most of these mistakes are not specific to Rust!
I am so happy to say that Michael Bryan is my mentor.
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!
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.
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
Awesome content as usual! Thanks for sharing those mistakes!
Damn, that's the first use of the "windows" method I've seen. Good job.
Enlightening for a beginner big thanks
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 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)
Unwrapping options is the bane of my existence
In my case, I am using too much unsafe code to deal with pointers, interior mutability u.u
Thanks for the video
Common mistake number -1 Not bothering to read the docs
array_windows() returns references , thats why you are using the copied() so you can grab the content of those references
I didn't know about array_windows, so thank you for that tip!
I'd argue that unless Error moves to core, one should avoid implementing it. It's one of the worst trait in the standard library.
It’s been added to core now
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!
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.
In mistake number 6 you did what you preached not to, and indexed into an array whithout checking if it was even empty.
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.
In last mistake the way you've gotten ridden of Rc and RefCell looks kinda like a functional programming approach, gettin rid of state
Wow I did not know most of those cool features!
Amazing video, congrats!
"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".
The mistakes experienced rust developers make would be interesting
functional programming approach reduce chances of using smart pointer
2:19 why you return int (32bit signed integer) but array length is size_t (64bit unsigned int)
Very interesting the last part of the game
6:28 that parsing code will panic if passed "(1,2,3)"? Seems like an example that teaches bad habits?
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
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.
Informative video - as usual! 👍
Array_windows docs have example like this:
let iter = slice.array_windows::();
I'm assuming that's incorrect... 2 isn't a type...
As per the language reference book, "GenericParam" may be any of "lifetime", "type" or "const". Const generic parameters allows you to avoid things like "vec2","vec3","vec4" you find in e.g. the OpenGL math library by just having a generic vec and defining it automatically each time it's invoked with a new constant in the code.
For the example of array_windows, are you sure the revised code is more efficient than the one using index?
Reductive coding supports less dependencies, in less languages, on unsupported devices.
Good and helpful as always.
Any toughts on the editor lapce?
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!
Great tips, thanks.
There's no way that CI works, right? There's no cargo installed in the base actions/checkout image?
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.
Why is pattern matching better than an if statement when checking for a boolean state? (Is_some)
Now this video is very useful. Cheers
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_.
Excelent tips!
this is awesome, thanks
Thanks, super useful
deadly? who died?
I did, but I'm fine now. Thanks for asking :)
we don't talk about Him
Huuuuuuuge! Congrats for that video! Really useful! 🎉🎉
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.
What's wrong with creating a properly named enum instead of meaningless error integers?
@@ДавидПлеван Why do you think, I'm talking about error integers?
I think, I basically had an index, but 0 did represent some default elemen, while 1 represented element 0 of an array.
@@porky1118 By returning some hard coded default value you cannot know if a function failed or not. I think by default your should use option, but if you need an infallible version, create a separate function like search_or(default: usize) -> usize.
Do you have a linter setup for this?
Help a lot👍🏻
9:00 I consider myself to be a experienced Rust programmer, I'm using Rust for 5 years maybe, but I still do or recently did some of the "beginner" mistakes. For example I didn't use clippy until maybe half a year ago.
But not using Rc and structuring programs differently is one of the first things I learned when using Rust. Probably after a year or so.
I guess, that's because I think, I'm smarter than everyone, and therefore ignore advice from other people and only look things up things, when I don't find solutions myself. So I only learn, what's really necessary/useful from experience. And using Rc is just annoying to work with, so I had to find a way to work around it.
4:45 What library?
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 ...
I think most of these simply go beyond a linter and go more into code generation territory: You need to understand the greater context to make a decision. Even something as simple as &String vs. &str depends on the context. But if an AI system understands the greater context, why not have it generate the code in the first place instead of just pointing out when you make mistakes? Things certainly seem to move in that direction...
Also, there are already clippy flags that check for some of these. For example clippy::new-without-default will trigger when you have a Something::new() not taking parameters but don't implement Default.
It's built into Rust
Thx very much 💖
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.
hey that looks like my code fr
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]
}