Excellent analysis of the debate. I already had an opinion on the subject, but this article helped illuminate to me why exactly I felt the way I did. > If the

Excellent analysis of the debate. I already had an opinion on the subject, but this article helped illuminate to me why exactly I felt the way I did. > If the function returns Err(NotAuthorized), I wouldn’t say it failed. I’d say it’s doing its job very well indeed. I worked in Java for a couple of years. Java loves its throw/catch-style error handling. But the mindset around exceptions in that sort of language is that they're exceptional. They're bad, they're ugly, you really want to just sweep them under the rug if you can. But you inevitably reach certain cases where your API throws an exception as a normal course of doing business - trying to open a file that doesn't exist, for example - and now exceptions become a core part of your business logic. Yet you can't really work with them like normal return values, you have to use this special, gross, control-flow-breaking syntax that's really only designed for putting out a fire, logging something, maybe cleaning up some locked resources. > but that would be an irregularity in otherwise quite regular and well-behaving language One of Rust's greatest strengths is that its extremely rich type system allows things that might receive special status in other languages to become "just types". I am in love with this trait (heh) of Rust. I didn't know how to articulate it before, but chipping away at that mental model would simply, above all, be deeply un-Rusty.