The difference with .map_err() is that you are no longer in the control flow of the parent function, so you can't decide to ignore the error inside the .map_err

The difference with .map_err() is that you are no longer in the control flow of the parent function, so you can't decide to ignore the error inside the .map_err(), and you can't decide to return/break there either. You end up combining .map_err() with ?. The "match" syntax is very simple, clear, and flexible. I don't have to remember the different Result methods: or(), map_err(), map_or_else(), and_then(), etc. There are just too many methods to remember, and match does everything. (Edit: and it's easier to borrow or move something from the enclosing scope inside 'match'.) If I later decide that the Err() branch inside the match needs to do something other than propagate an error, I can just change the code there, without having to change the .map_err() to something else. I like match because it's simple, easy to read, easy to write, and flexible. In Haskell, I’m more comfortable using functions like Rust's map_err because I can, e.g., put it on the outside of a "do" block, and in Haskell, it’s not like you’re going to "break" or "return" anyway (not in the imperative sense). In other words, in Haskell, something like mapError has the same power as "case" does (and perhaps more, since there are multiple ways to propagate errors in Haskell, and mapError will handle all of them, as long as you’re in an error-handling monad).