This is my experience every time I return to learning rust. I’m guessing that if I used it more often than once a quarter with hobby projects I’d stop falling into the same traps.
Yeah, these become a lot less relevant with routine.
Avoiding the main-thread panicking is mostly just a matter of not using .unwrap() and .expect().
String vs. &str can mostly be solved by generally using owned datatypes (String) for storing in structs and using references (&str) for passing into function parameters. It does still happen that you forget the & at times, but that’s then trivial to solve (by just adding the &).
“temporary value dropped while borrowed” can generally be avoided by not passing references outside of your scope/function. You want to pass the owned value outside. Clone, if you have to.
“missing lifetime specifier” is also largely solved by not storing references in structs.
The last two points are the kind of design advice I need to see. I’m probably so used to the C/C++ concept of passing by reference to prevent copies of complex data being generated that I forget how Rust’s definition of a reference is different.
I think they do a good job of pointing out “this is a behavior/feature of Rust you need to understand.” However they can send you down the wrong path of correction.
The compiler error mentioning static lifetime specifiers of &str demonstrates both. It indicates to the developer that ownership and scopes will play a significant role when defining and accessing data. The error though will guide them towards researching how to define static lifetimes and possibly believe that they will need to set this in their functions and structs. Each time you look at questions about this error in places like Stack Overflow with example code you’ll find suggested solutions explaining that a manually-defined static lifetime isn’t necessary to resolve the problem.
This is my experience every time I return to learning rust. I’m guessing that if I used it more often than once a quarter with hobby projects I’d stop falling into the same traps.
Yeah, these become a lot less relevant with routine.
Avoiding the main-thread panicking is mostly just a matter of not using
.unwrap()and.expect().Stringvs.&strcan mostly be solved by generally using owned datatypes (String) for storing in structs and using references (&str) for passing into function parameters. It does still happen that you forget the&at times, but that’s then trivial to solve (by just adding the&).“temporary value dropped while borrowed” can generally be avoided by not passing references outside of your scope/function. You want to pass the owned value outside. Clone, if you have to.
“missing lifetime specifier” is also largely solved by not storing references in structs.
The last two points are the kind of design advice I need to see. I’m probably so used to the C/C++ concept of passing by reference to prevent copies of complex data being generated that I forget how Rust’s definition of a reference is different.
I find that the error messages themselves are a great tool for learning when it comes to Rust.
Eh, I’m not entirely sold on that idea.
I think they do a good job of pointing out “this is a behavior/feature of Rust you need to understand.” However they can send you down the wrong path of correction.
The compiler error mentioning static lifetime specifiers of
&strdemonstrates both. It indicates to the developer that ownership and scopes will play a significant role when defining and accessing data. The error though will guide them towards researching how to define static lifetimes and possibly believe that they will need to set this in their functions and structs. Each time you look at questions about this error in places like Stack Overflow with example code you’ll find suggested solutions explaining that a manually-defined static lifetime isn’t necessary to resolve the problem.