3 ms·

This seems incredibly bad faith—using "unwrap" is closer to using an assert than it is at being "user facing messaging". Asserts don't typically come with manua

This seems incredibly bad faith—using "unwrap" is closer to using an assert than it is at being "user facing messaging". Asserts don't typically come with manuals explaining what the user should do to fix the software. We all have moments when we're developing software and haven't fully developed the domain. Not requiring exhaustive error handling during this process is a massive help. Obviously, fully enumerated errors are good, and catering diagnostics to the users is even better. But there's more to software than shipping perfect code.

nixpulvis 1y ago
I do not understand your point. Are you saying more code should use asserts for catching error cases? Nobody's saying perfection is 100% required, but there are ideals and we should aim for them and design with principle. One of those principals should be quality error messages. Hell, the rust compiler itself is a great case study for how improving error messages for users massively helps with adoption and quality of life. It's pretty rare that you hit an internal compiler error (ICE) too which is nice.
- MangoToupe 1y ago
  I'm certainly not against high-quality diagnostics, I'm just saying that few people expect an unwrap to be sufficient for this, and it's odd to me to look at an unwrap and see it as error messaging (outside of what an assert is supposed to provide—eg a clear inconsistency in logic a developer needs to interpret). But to figure out which errors you need to appropriately parameterize and pass up the stack, you first need to understand what you're building. Without unwrap, we would basically have to engage in exhaustive enumeration as we develop. Which is fine, if you're willing to put that effort in! But that's part of why things like Haskell can struggle to win people over—for better or worse, half-broken code (semantically, in domain terms) that compiles and runs is a powerful tool mid-feature. But yes, this does require that people care about diagnostics to begin with. I don't think that's worth forcing; most of us develop this instinct through frustration at dealing with the fallout of someone not caring. (And FWIW I find the combination of explicitly-structured Results that are manually passed up the stack with RAII to be a very, very sweet spot for development velocity, and also easy to teach. I very much prefer this to both exceptions and go's approach.)

nixpulvis 1y ago

I do not understand your point. Are you saying more code should use asserts for catching error cases? Nobody's saying perfection is 100% required, but there are ideals and we should aim for them and design with principle. One of those principals should be quality error messages. Hell, the rust compiler itself is a great case study for how improving error messages for users massively helps with adoption and quality of life. It's pretty rare that you hit an internal compiler error (ICE) too which is nice.

MangoToupe 1y ago
I'm certainly not against high-quality diagnostics, I'm just saying that few people expect an unwrap to be sufficient for this, and it's odd to me to look at an unwrap and see it as error messaging (outside of what an assert is supposed to provide—eg a clear inconsistency in logic a developer needs to interpret). But to figure out which errors you need to appropriately parameterize and pass up the stack, you first need to understand what you're building. Without unwrap, we would basically have to engage in exhaustive enumeration as we develop. Which is fine, if you're willing to put that effort in! But that's part of why things like Haskell can struggle to win people over—for better or worse, half-broken code (semantically, in domain terms) that compiles and runs is a powerful tool mid-feature. But yes, this does require that people care about diagnostics to begin with. I don't think that's worth forcing; most of us develop this instinct through frustration at dealing with the fallout of someone not caring. (And FWIW I find the combination of explicitly-structured Results that are manually passed up the stack with RAII to be a very, very sweet spot for development velocity, and also easy to teach. I very much prefer this to both exceptions and go's approach.)