3 ms·

I should probably write a blog post about this or something. My big criticism of Ok-Wrapping is that it hides complexity in a way that's at odds with the rest

I should probably write a blog post about this or something. My big criticism of Ok-Wrapping is that it hides complexity in a way that's at odds with the rest of the language. Rust's big benefit to me is that it surfaces complexity. It makes me deal with it right now, at the time I write code. Even though async munges the type of my function, it feels different because it's explicit and has to be done at the point that I conceive of the function.

bcheung 7y ago
Well the other end of the spectrum of surfacing complexity of errors would be idiomatic Golang code. But then half your code becomes "if err != nil" error handling. In many scenarios error handling can be automated because the essence of what you typically do when there are errors is to short-circuit the rest of the function and surface the error the user. If you are doing it the same way each time, you might as well abstract it. In some cases you may want to make things explicit and force the programmer to deal with them. But if it is just boilerplate, then it becomes noise, and an excessive amount of noise prevents the programmer from thinking at a higher level of abstraction. Due to limits of human cognition / mental bandwidth (7 +/- 2 concepts at a time), abstraction compresses the number of concepts you need to concern yourself with, and that means you can focus more on the problem domain and less on boilerplate. The key to this though is learning new concepts and abstractions. Each abstraction compresses multiple thoughts into 1, freeing up cognitive bandwidth. The more concepts and abstractions you know, the more efficient and higher level thoughts you can have. But that requires time to learn and master. You might also have lots of junior programmers on a team, in which case they are not familiar with many higher level abstractions and they will not be able to work on a codebase, so you have to keep that in balance.
- _bxg1 7y ago
  For cases where you're confident a Result won't be an error, it has a .unwrap() method that allows you to skip handling the error case and escalates it to a panic instead. You can even pass a custom error-message string.
qppo 7y ago
Rust's expressiveness of complexity is mirrored by its complexity of expression. I don't think that Ok-Wrapping hides complexity. I think it's a filled in pothole for sum type semantics in Rust. I don't think the best solution is sugar, but completely redoing the syntax. And that will likely never be possible in stable Rust.
- comex 7y ago
  Out of curiosity, what kind of syntax do you think would be better?
  - qppo 7y ago
    Anonymous sum types. Most enum variants I write are single use, or very few use. We have anonymous product/record types with tuples (function returns all-of) but not variants (function returns one-of). Something like fn foo() -> (i32 | f32 | String). I'm not the first person to suggest this idea, and it's been done in other languages. As well, having to match against Enum::Variant0, EnumVariant::1, etc, for all arms of a match statement instead of inferring that it would be Variant0, Variant1 is tedious. These changes would be difficult to implement and I know some people prefer to have all of the explicitness in their code. But one of the most common complaints outside the community is that prototyping in Rust is slow. Not just because of the borrow checker, that's easy once you learn it. It's the over-emphasis on explicitness at the expense of ergonomics.
notacoward 7y ago
> I should probably write a blog post about this or something. Please do. I did. Shameless self-plug: https://obdurodon.silvrback.com/error-handling https://obdurodon.silvrback.com/error-handling Maybe you'll find something of interest there, even if it's something to disagree with. That's fine; contrast improves visibility. Having written that just before the current surge of interest in the subject, I'm finding many of the discussions quite fascinating.
- eximius 7y ago
  Its interesting, but I'm not sure that your proposal still qualifies as concise. Nor am I sure that ADT-based error handling (Option/Result/etc) belongs should be considered silently dropped. Option certainly sees some abuse, but on the whole, `unwrap()` is a red flag that draws my attention. And, in Rust, with pattern matching and `?` to propagate errors, I see errors handled more often than not.

bcheung 7y ago

Well the other end of the spectrum of surfacing complexity of errors would be idiomatic Golang code. But then half your code becomes "if err != nil" error handling. In many scenarios error handling can be automated because the essence of what you typically do when there are errors is to short-circuit the rest of the function and surface the error the user. If you are doing it the same way each time, you might as well abstract it. In some cases you may want to make things explicit and force the programmer to deal with them. But if it is just boilerplate, then it becomes noise, and an excessive amount of noise prevents the programmer from thinking at a higher level of abstraction. Due to limits of human cognition / mental bandwidth (7 +/- 2 concepts at a time), abstraction compresses the number of concepts you need to concern yourself with, and that means you can focus more on the problem domain and less on boilerplate. The key to this though is learning new concepts and abstractions. Each abstraction compresses multiple thoughts into 1, freeing up cognitive bandwidth. The more concepts and abstractions you know, the more efficient and higher level thoughts you can have. But that requires time to learn and master. You might also have lots of junior programmers on a team, in which case they are not familiar with many higher level abstractions and they will not be able to work on a codebase, so you have to keep that in balance.

_bxg1 7y ago
For cases where you're confident a Result won't be an error, it has a .unwrap() method that allows you to skip handling the error case and escalates it to a panic instead. You can even pass a custom error-message string.

qppo 7y ago

Rust's expressiveness of complexity is mirrored by its complexity of expression. I don't think that Ok-Wrapping hides complexity. I think it's a filled in pothole for sum type semantics in Rust. I don't think the best solution is sugar, but completely redoing the syntax. And that will likely never be possible in stable Rust.

comex 7y ago
Out of curiosity, what kind of syntax do you think would be better?
- qppo 7y ago
  Anonymous sum types. Most enum variants I write are single use, or very few use. We have anonymous product/record types with tuples (function returns all-of) but not variants (function returns one-of). Something like fn foo() -> (i32 | f32 | String). I'm not the first person to suggest this idea, and it's been done in other languages. As well, having to match against Enum::Variant0, EnumVariant::1, etc, for all arms of a match statement instead of inferring that it would be Variant0, Variant1 is tedious. These changes would be difficult to implement and I know some people prefer to have all of the explicitness in their code. But one of the most common complaints outside the community is that prototyping in Rust is slow. Not just because of the borrow checker, that's easy once you learn it. It's the over-emphasis on explicitness at the expense of ergonomics.

notacoward 7y ago

> I should probably write a blog post about this or something. Please do. I did. Shameless self-plug: https://obdurodon.silvrback.com/error-handling https://obdurodon.silvrback.com/error-handling Maybe you'll find something of interest there, even if it's something to disagree with. That's fine; contrast improves visibility. Having written that just before the current surge of interest in the subject, I'm finding many of the discussions quite fascinating.

eximius 7y ago
Its interesting, but I'm not sure that your proposal still qualifies as concise. Nor am I sure that ADT-based error handling (Option/Result/etc) belongs should be considered silently dropped. Option certainly sees some abuse, but on the whole, `unwrap()` is a red flag that draws my attention. And, in Rust, with pattern matching and `?` to propagate errors, I see errors handled more often than not.