Some things occasionally feel too verbose. For example, converting between str and String [...] seems like something the compiler could figure out for m

Some things occasionally feel too verbose. For example, converting between str and String [...] seems like something the compiler could figure out for me. I’m sure there’s a good reason for why it is the way it is This in particular has a very good reason — converting from a `&str` to a `String` requires memory allocation. You don't want to start accidentally allocating memory! See also: - Why is it discouraged to accept a reference to a String (&String), Vec (&Vec), or Box (&Box) as a function argument? (https://stackoverflow.com/q/40006219/155423 https://stackoverflow.com/q/40006219/155423) Having to handle every Result from every function is good; it means the programmer has to think about what’s happening with every function call. Sometimes it feels tedious. [...] you still need to explicitly define a case for every type of error that may occur. You are not required to create a case for every type of error (although I think it's good to). You can use a trait object (`Box<dyn Error>`) if you truly don't care about the type. See also: - Recoverable Errors with Result (https://doc.rust-lang.org/stable/book/ch09-02-recoverable-errors-with-result.html https://doc.rust-lang.org/stable/book/ch09-02-recoverable-er...) I find myself frequently writing code similar to option.as_ref().unwrap().borrow(), which feels icky. I can't imagine a case where this particular set of methods is needed (and as a sibling comment mentions, you can often avoid `unwrap` via pattern matching), but there is the unstable `Option::deref`, which shortens this code: fn example(a: Option<String>) { // Before let b: Option<&str> = a.as_ref().map(|s| &**s); // After let b: Option<&str> = a.deref(); } See also: - `Option::deref` (https://doc.rust-lang.org/std/option/enum.Option.html#method.deref https://doc.rust-lang.org/std/option/enum.Option.html#method...)