4 ms·

> I really want Rust to succeed, but I think they took a wrong turn with error handling. Wow, I have exactly the opposite impression. I am so excited by how el

> I really want Rust to succeed, but I think they took a wrong turn with error handling. Wow, I have exactly the opposite impression. I am so excited by how elegantly error handling is done in Rust. > Having to write all that error handling code up front is going to be a big problem for the Agile crowd. I really disagree. At my last job (Pivotal Labs, definitely part of the 'Agile crowd'), large internal projects have been ported from Ruby to Go. There are a lot of things I don't like about Go, but one thing that everyone I worked with really enjoyed about it was the clarity and explicitness of the error handling. Exceptions are hard to reason about and hard to remember to handle; errors returned from functions are so simple. It seems like Rust's error handling has the good properties of Go's, but it allows for more abstraction because of Rust's more powerful type system. I think the Agile crowd that I've hung out with is going to love it.

skybrian 11y ago
The difference seems to be that Go has a preferred way to do it: explicit case analysis and early returns. There are other approaches but they're used much less and rarely exposed in API's. Meanwhile, apparently the Rust folks can't make up their minds, so they support lots of different functional styles of error handling.
- maxbrunsfeld 11y ago
  > The difference seems to be that Go has a preferred way to do it: explicit case analysis and early returns. In other words, there is no way to abstract over the case analysis in Go. It sounds like you're saying this is a good thing. I think it's bad. > ... apparently the Rust folks can't make up their minds Wow, I'd say the opposite. In Go, the only thing all `error` objects have in common is the `Error()` method, which returns a description. If you want to investigate the causal chain of an error (to achieve what stack-traces give you in languages with exceptions), there is no standard way, even for errors in the standard library. Some errors are basically just strings, others are structs with other fields that you can access by using runtime type assertions. Rust, on the other hand, has the `Error` trait, which includes a `cause` method, returning the underlying error if one exists. This alone seems to me like an improvement in consistency over Go.
  - skybrian 11y ago
    I agree that having a standard cause chain is important. +1 for Rust. But I don't think abstracting over case analysis is a good idea when it hurts readability. The combinator stuff looks like it's adding layers of shortcut notations that obscure the control flow.
    - burntsushi 11y ago
      If you continue to read the OP, you'll get to the `try!` macro, which is a completely different beast. ;-) (It also abstracts over case analysis, among other things, but it's only one very simple form of case analysis, so the mental overhead is low. Combinators on the other hand abstract over many different types of case analysis, so the mental burden can be high, especially if you aren't already comfortable using them.)
- pcwalton 11y ago
  > The difference seems to be that Go has a preferred way to do it: explicit case analysis and early returns. There are other approaches but they're used much less and rarely exposed in API's. The API signature is always the same regardless of how the caller handles errors: a function returning Result. The differences are never exposed in APIs (arguably even less than in Go, since you can't recover from a panic in Rust except at thread boundaries). > Meanwhile, apparently the Rust folks can't make up their minds, so they support lots of different functional styles of error handling. They all boil down to the same thing. There's no inability to make up our minds with error handling any more than supporting both for-loops and map represents inability to make up our minds. Nobody dings Python for supporting list comprehensions in addition to for loops. Sometimes functional programming is short and sweet, and you should be able to use it; other times, for loops are better. and_then() is just the functional syntax to "try!"'s imperative syntax.
  - skybrian 11y ago
    It's good that the API signature is consistent. It seems like having lots of trivial error combinators is less like Python's list comprehensions and more like what came before it. I'll point out that Guido has had second thoughts about lambda, reduce(), filter() and map(), though in the end he only dropped reduce. [1]. [1] http://www.artima.com/weblogs/viewpost.jsp?thread=98196 http://www.artima.com/weblogs/viewpost.jsp?thread=98196
- Manishearth 11y ago
  Go's design generally picks a use case and focuses on it (the designers have made many choices which fit their use cases but are inelegant for others); Rust tries to address as many use cases as possible (which also leads to inelegant code at times :P).

skybrian 11y ago

The difference seems to be that Go has a preferred way to do it: explicit case analysis and early returns. There are other approaches but they're used much less and rarely exposed in API's. Meanwhile, apparently the Rust folks can't make up their minds, so they support lots of different functional styles of error handling.

maxbrunsfeld 11y ago
> The difference seems to be that Go has a preferred way to do it: explicit case analysis and early returns. In other words, there is no way to abstract over the case analysis in Go. It sounds like you're saying this is a good thing. I think it's bad. > ... apparently the Rust folks can't make up their minds Wow, I'd say the opposite. In Go, the only thing all `error` objects have in common is the `Error()` method, which returns a description. If you want to investigate the causal chain of an error (to achieve what stack-traces give you in languages with exceptions), there is no standard way, even for errors in the standard library. Some errors are basically just strings, others are structs with other fields that you can access by using runtime type assertions. Rust, on the other hand, has the `Error` trait, which includes a `cause` method, returning the underlying error if one exists. This alone seems to me like an improvement in consistency over Go.
- skybrian 11y ago
  I agree that having a standard cause chain is important. +1 for Rust. But I don't think abstracting over case analysis is a good idea when it hurts readability. The combinator stuff looks like it's adding layers of shortcut notations that obscure the control flow.
  - burntsushi 11y ago
    If you continue to read the OP, you'll get to the `try!` macro, which is a completely different beast. ;-) (It also abstracts over case analysis, among other things, but it's only one very simple form of case analysis, so the mental overhead is low. Combinators on the other hand abstract over many different types of case analysis, so the mental burden can be high, especially if you aren't already comfortable using them.)
pcwalton 11y ago
> The difference seems to be that Go has a preferred way to do it: explicit case analysis and early returns. There are other approaches but they're used much less and rarely exposed in API's. The API signature is always the same regardless of how the caller handles errors: a function returning Result. The differences are never exposed in APIs (arguably even less than in Go, since you can't recover from a panic in Rust except at thread boundaries). > Meanwhile, apparently the Rust folks can't make up their minds, so they support lots of different functional styles of error handling. They all boil down to the same thing. There's no inability to make up our minds with error handling any more than supporting both for-loops and map represents inability to make up our minds. Nobody dings Python for supporting list comprehensions in addition to for loops. Sometimes functional programming is short and sweet, and you should be able to use it; other times, for loops are better. and_then() is just the functional syntax to "try!"'s imperative syntax.
- skybrian 11y ago
  It's good that the API signature is consistent. It seems like having lots of trivial error combinators is less like Python's list comprehensions and more like what came before it. I'll point out that Guido has had second thoughts about lambda, reduce(), filter() and map(), though in the end he only dropped reduce. [1]. [1] http://www.artima.com/weblogs/viewpost.jsp?thread=98196 http://www.artima.com/weblogs/viewpost.jsp?thread=98196
Manishearth 11y ago
Go's design generally picks a use case and focuses on it (the designers have made many choices which fit their use cases but are inelegant for others); Rust tries to address as many use cases as possible (which also leads to inelegant code at times :P).