4 ms·
> lazy software engineering For production code, I agree with you. When writing PoC software, using those can speed up development, rather than forcing you to
by bluejekyll 6y ago
> lazy software engineering
For production code, I agree with you. When writing PoC software, using those can speed up development, rather than forcing you to figure out the best way to deal with those options or errors upfront. Refactoring in Rust tends to also make it reliably produce production quality code when you go back and fix all that.
On the “?” In examples, that can also lead to annoyance for a new to Rust Dev, getting error return types correct, or knowing to leverage crates like anyhow, can be complex at first. Unwrap and expect are great ways to get started. I also make heavy use of them in test code.
- dthul 6y agoOh yeah absolutely, for prototypes you can liberally use unwrap/expect to figure out the happy path first and remove those calls later. I haven't checked out the Rust book in quite some time, but it would be cool to make newcomers comfortable with the Result<..., Box<dyn Error>> return type early on, so they know what they have to do to make code containing "?" compile.