It's nice to use the ? operator, but if you also want to include logging/metrics, I really recommend using `match` to make it clear what each branch does.
> Embrace the newtype pattern
A nice pattern for certain use cases, but often abused by programmers. Out of the box, a newtype is less useful than the type it wraps, because it has none of the underlying type's methods. This results in either having a ton of boiler-plate code that just does `self.0.underlying_method()` or in programmers making the wrapped value public, which defeats the purpose.
"Embrace" to me means "use it when possible", but my experience says that it should be like spice, a little bit can improve the dish, but too much can ruin it.
> Consider using iterator transforms instead of explicit loops
Similar comment to the point about avoiding matches for Option and Result. For simple use cases, a .map() or .filter() can be good and easy to read, but I've also seen monstrosities with .skip(), .filter_map(), .chunks(), etc. that become a lot harder to decipher than the equivalent for-loop. We also tend to try and write those in an FP style with no side effects, and sometimes that can discourage people from including logs and metrics in places where they would be useful because they would tarnish the purity of the code.
Whatsmore, in Rust closures are more finicky than in GC'ed languages like OCaml or F#, and some iterator methods take their closure parameters by ownership, others borrow, and it's very often an unnecessary mental burden.
> Don't panic
Good idea in general, but panicking is a great tool when the program is in a state that was not predicted by the programmer or cannot be recovered from. "In general, avoid panicking" would be better advice.
> Minimize visibility
It's been accepted since the advent of OOP that we should aim to minimize the visibility of the data in our structures. Every Java IDE defaults to making fields private and auto-generating getters and setters. But more often than not, when programmers hide all the internal details, they limit what other programmers. Yes, other programmers could use the API wrong and create bugs in their programs, but they could also use it in ways that the original programmer could not have anticipated and make something amazing out of it.
And when other programmers complain that they are limited in what they can do, the answer is always "we'll add more stuff (traits, plugins, closure parameters, etc.) to help you do more", increasing the complexity of the code.
> Listen to Clippy
Some of the warnings from clippy are good (e.g., when it reminds you to use .unwrap_or_else() instead of .unwrap_or()), but a lot of the lints are opinions made into code, and people view you very suspiciously if you disable any of them, which drives the general style of Rust toward the style of the people who successfully argued for their opinions to be part of clippy.
For example, I like putting return statements in my code; yes clippy, I know that the value of a block is the value of its last expression and thus it's unnecessary to put the return, but I want to make it more explicit that we are exiting the function here, why are you complaining about that?
> Good idea in general, but panicking is a great tool when the program is in a state that was not predicted by the programmer or cannot be recovered from. "In general, avoid panicking" would be better advice.
The disclaimer at the top of the item agrees:
> The title of this Item would be more accurately described as: prefer returning a Result to using panic! (but don't panic is much catchier).
Later on:
> If an error situation should only occur because (say) internal data is corrupted, rather than as a result of invalid inputs, then triggering a panic! is legitimate.
Most of your criticism boils down to "general idea is fine, but there are important special cases". Which is expected, to be honest. It's difficult to give general guidance that's correct for everyone.
> A nice pattern for certain use cases, but often abused by programmers. Out of the box, a newtype is less useful than the type it wraps, because it has none of the underlying type's methods. This results in either having a ton of boiler-plate code that just does `self.0.underlying_method()` or in programmers making the wrapped value public, which defeats the purpose.
It's nice to use the ? operator, but if you also want to include logging/metrics, I really recommend using `match` to make it clear what each branch does.
> Embrace the newtype pattern
A nice pattern for certain use cases, but often abused by programmers. Out of the box, a newtype is less useful than the type it wraps, because it has none of the underlying type's methods. This results in either having a ton of boiler-plate code that just does `self.0.underlying_method()` or in programmers making the wrapped value public, which defeats the purpose.
"Embrace" to me means "use it when possible", but my experience says that it should be like spice, a little bit can improve the dish, but too much can ruin it.
> Consider using iterator transforms instead of explicit loops
Similar comment to the point about avoiding matches for Option and Result. For simple use cases, a .map() or .filter() can be good and easy to read, but I've also seen monstrosities with .skip(), .filter_map(), .chunks(), etc. that become a lot harder to decipher than the equivalent for-loop. We also tend to try and write those in an FP style with no side effects, and sometimes that can discourage people from including logs and metrics in places where they would be useful because they would tarnish the purity of the code.
Whatsmore, in Rust closures are more finicky than in GC'ed languages like OCaml or F#, and some iterator methods take their closure parameters by ownership, others borrow, and it's very often an unnecessary mental burden.
> Don't panic
Good idea in general, but panicking is a great tool when the program is in a state that was not predicted by the programmer or cannot be recovered from. "In general, avoid panicking" would be better advice.
> Minimize visibility
It's been accepted since the advent of OOP that we should aim to minimize the visibility of the data in our structures. Every Java IDE defaults to making fields private and auto-generating getters and setters. But more often than not, when programmers hide all the internal details, they limit what other programmers. Yes, other programmers could use the API wrong and create bugs in their programs, but they could also use it in ways that the original programmer could not have anticipated and make something amazing out of it.
And when other programmers complain that they are limited in what they can do, the answer is always "we'll add more stuff (traits, plugins, closure parameters, etc.) to help you do more", increasing the complexity of the code.
> Listen to Clippy
Some of the warnings from clippy are good (e.g., when it reminds you to use .unwrap_or_else() instead of .unwrap_or()), but a lot of the lints are opinions made into code, and people view you very suspiciously if you disable any of them, which drives the general style of Rust toward the style of the people who successfully argued for their opinions to be part of clippy.
For example, I like putting return statements in my code; yes clippy, I know that the value of a block is the value of its last expression and thus it's unnecessary to put the return, but I want to make it more explicit that we are exiting the function here, why are you complaining about that?