Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Is it time to brag about Rust error-handling or should we wait a little?


It's certainly better than Go's (Go's is barely better than C's and that's quite a low bar), but I don't think that sum types are the global optimum.

Exceptions are arguably better from certain aspects, e.g. defaulting to bubbling up, covering as small or wide range as needed (via try-catch blocks), and auto-unwrapping without plus syntax. So when languages with proper effect types come into mainstream we might reach a higher optimum.


Maybe I'm too pessimistic, but Rust style error handling feels like the global optimum under the constraint that the average developer understand it.

Go is a language that exists purely because people saw Monads in the horizon and, in their panic, went back to monke, programming wise. Rust error handling is something that even many Go fans have said is a good abstraction.


No, sum types are certainly not a global optimum. But they remain the best error-handling mechanism that I've used professionally so far.

Effect types (and effect handlers) are very nice, but they come with their own complexities. We'll see if some mainstream language manages to make them popular.


After a decade of Scala and Rust I no longer believe in monads and prefer the way Go does error handling.

  for a <- a()
      b <- b() {
      return a + b
  }
  
looks nice but only by hiding error handling. Today I like looking at code and see the error handling. With monads you end up with monad stacks and transformers which introduce their own failure states.


I haven't played with Scala in a while, but Rust's error-handling is not syntactically monadic. If you look at the code, you don't see combinators, you see either error propagation or error handling.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: