5 ms·

"Isn't the "noise problem" with Go error handling the control flow rather than the lack of generics?" It's both. Adding only concise flow control, such as wit

"Isn't the "noise problem" with Go error handling the control flow rather than the lack of generics?" It's both. Adding only concise flow control, such as with the ? operator, works poorly if all you can return is multiple non-generic values; various common permutations get awkward in that case. And as you point out Result<> doesn't achieve much without the concise operators. Rust has very successfully shown the benefit of the combination.

ipmonkey 5y ago
Early return is definitely a part of the problem. One thing you could do with generics is create option/result wrappers that would work with any code and hack together a try/early return solution using panic/recover, but you'd offend the Go community, and at that point you might as well just use Rust.
tptacek 5y ago
I wrote a comment here pushing back somewhat on the idea that Rust has much better error handling ergonomics (not correctness, where it clearly wins, but ergonomics) but thought better of it; debating Go vs. Rust is about the least productive thing we can do on HN.
- rustnote 5y ago
  I like what Chris Lattner said about language design in Lex Fridman podcast, that you know when you're doing something right because it "feels" right. Rust has a bunch of syntactic sugar which gets critised in many languages, but to me things like error returns with ? "feels" right. Love Go as well, and the error handling makes a lot of sense in concept but it just doesn't "feel" nice to look at or use. I like there's a language that has such a strong vision, but dealing in absolutes has drawbacks, a little sytactic sugar would make error handling a lot nicer.
  - fourseventy 5y ago
    For what it's worth I really like how go handles errors.
    - shakezula 5y ago
      I’m with you in this one, Go’s error handling was intuitive to me. It was my first compiled and typed language, though. That might bias my experience.
  - jatone 5y ago
    eh having used both, rust's approach isn't any better. when you need to decorate an error, which generally is a lot of the time, rust has the same ergonomics as golang. they optimized code for a generally rare situation. I do appreciate rusts match syntax though.
  - otabdeveloper4 5y ago
    > that you know when you're doing something right because it "feels" right Absolutely false. When you write the really groundbreaking and important software "feels right" is absolutely not what you should be experiencing. The correct mode you should be in is "holy fuck how did I get here, and can I come out in one piece"? (A: no, you can't, but the new you will be a better you.)
- baby 5y ago
  If you don’t have a result type then you don’t have better error handling!
  - 1_player 5y ago
    Zig disagrees. Monads are cool and all, but we can do better than Result for error handling.
    - masklinn 5y ago
      Result is monadic but not necessarily a monad. From what I know of zig’s error handling, I really don’t think it’s better than result types. It is less work, especially when using error unions (though I think that makes it easier to miss changes to error sets as they’re implicit), but since errors are literally just u16 they’re also deeply lacking in richness and composability. It’s definitely an improvement over C’s error style, and thus perfectly understandable given zig’s goal, but I very much disagree that it’s “better than Result”. It’s also extremely magical in that it needs special language-level support throughout in ways Result is not, but obviously that’s more of a matter of taste.
      - 1_player 5y ago
        > It’s also extremely magical in that it needs special language-level support throughout in ways Result is not, but obviously that’s more of a matter of taste. That's a peculiar observation, it's like saying Rust's borrow checker is magical because it needs language-level support. I mean, that's the point. In any case re: zig error or rust's Result, I don't think either of us are discussing features and pros/cons, but just describing what we like the best. Not very objective an argument. > but since errors are literally just u16 they’re also deeply lacking in richness and composability Zig errors are composable: https://ziglang.org/documentation/master/#Merging-Error-Sets https://ziglang.org/documentation/master/#Merging-Error-Sets and later sections.
        masklinn 5y ago
        > That's a peculiar observation, it's like saying Rust's borrow checker is magical because it needs language-level support. I mean, that's the point. You can’t do borrow checking without language support (I think, at least not without a significantly more expressive type system) whereas Result is pretty much just a type, the features it uses are mostly non-exclusive, and those which are, are very much intended not to remain so (e.g. the `Try` trait for the `?` operator). > Zig errors are composable: https://ziglang.org/documentation/master/#Merging-Error-Sets https://ziglang.org/documentation/master/#Merging-Error-Sets and later sections. Not really? That’s just merging error sets, but you can’t say that you’ve got an error which originally comes from an other error, except by creating its dual and documenting it as such. Essentially your choices are full transparency or full type erasure.

ipmonkey 5y ago

Early return is definitely a part of the problem. One thing you could do with generics is create option/result wrappers that would work with any code and hack together a try/early return solution using panic/recover, but you'd offend the Go community, and at that point you might as well just use Rust.

tptacek 5y ago

I wrote a comment here pushing back somewhat on the idea that Rust has much better error handling ergonomics (not correctness, where it clearly wins, but ergonomics) but thought better of it; debating Go vs. Rust is about the least productive thing we can do on HN.

rustnote 5y ago
I like what Chris Lattner said about language design in Lex Fridman podcast, that you know when you're doing something right because it "feels" right. Rust has a bunch of syntactic sugar which gets critised in many languages, but to me things like error returns with ? "feels" right. Love Go as well, and the error handling makes a lot of sense in concept but it just doesn't "feel" nice to look at or use. I like there's a language that has such a strong vision, but dealing in absolutes has drawbacks, a little sytactic sugar would make error handling a lot nicer.
- fourseventy 5y ago
  For what it's worth I really like how go handles errors.
  - shakezula 5y ago
    I’m with you in this one, Go’s error handling was intuitive to me. It was my first compiled and typed language, though. That might bias my experience.
- jatone 5y ago
  eh having used both, rust's approach isn't any better. when you need to decorate an error, which generally is a lot of the time, rust has the same ergonomics as golang. they optimized code for a generally rare situation. I do appreciate rusts match syntax though.
- otabdeveloper4 5y ago
  > that you know when you're doing something right because it "feels" right Absolutely false. When you write the really groundbreaking and important software "feels right" is absolutely not what you should be experiencing. The correct mode you should be in is "holy fuck how did I get here, and can I come out in one piece"? (A: no, you can't, but the new you will be a better you.)
baby 5y ago
If you don’t have a result type then you don’t have better error handling!
- 1_player 5y ago
  Zig disagrees. Monads are cool and all, but we can do better than Result for error handling.
  - masklinn 5y ago
    Result is monadic but not necessarily a monad. From what I know of zig’s error handling, I really don’t think it’s better than result types. It is less work, especially when using error unions (though I think that makes it easier to miss changes to error sets as they’re implicit), but since errors are literally just u16 they’re also deeply lacking in richness and composability. It’s definitely an improvement over C’s error style, and thus perfectly understandable given zig’s goal, but I very much disagree that it’s “better than Result”. It’s also extremely magical in that it needs special language-level support throughout in ways Result is not, but obviously that’s more of a matter of taste.
    - 1_player 5y ago
      > It’s also extremely magical in that it needs special language-level support throughout in ways Result is not, but obviously that’s more of a matter of taste. That's a peculiar observation, it's like saying Rust's borrow checker is magical because it needs language-level support. I mean, that's the point. In any case re: zig error or rust's Result, I don't think either of us are discussing features and pros/cons, but just describing what we like the best. Not very objective an argument. > but since errors are literally just u16 they’re also deeply lacking in richness and composability Zig errors are composable: https://ziglang.org/documentation/master/#Merging-Error-Sets https://ziglang.org/documentation/master/#Merging-Error-Sets and later sections.
      - masklinn 5y ago
        > That's a peculiar observation, it's like saying Rust's borrow checker is magical because it needs language-level support. I mean, that's the point. You can’t do borrow checking without language support (I think, at least not without a significantly more expressive type system) whereas Result is pretty much just a type, the features it uses are mostly non-exclusive, and those which are, are very much intended not to remain so (e.g. the `Try` trait for the `?` operator). > Zig errors are composable: https://ziglang.org/documentation/master/#Merging-Error-Sets https://ziglang.org/documentation/master/#Merging-Error-Sets and later sections. Not really? That’s just merging error sets, but you can’t say that you’ve got an error which originally comes from an other error, except by creating its dual and documenting it as such. Essentially your choices are full transparency or full type erasure.