8 ms·
Very reasonable caveats for a feature as big as generics. Personally, I'm super excited for the potential generics has to make error handling in Go less noisy,
by dgunay 5y ago
Very reasonable caveats for a feature as big as generics.
Personally, I'm super excited for the potential generics has to make error handling in Go less noisy, so I'll be attempting to use it ASAP.
- benhoyt 5y agoIsn't the "noise problem" with Go error handling the control flow rather than the lack of generics? You want to return early (and potentially add context to the error) if there was an error, otherwise continue on. How are you thinking of solving this with generics? The previous try() proposal added new control flow. That's part of the reason it was criticized so heavily -- it hid a control flow construct in something that looked like a function.
- javier2 5y agoIt is both, because multiple return values break function chaining.
- dgunay 5y agoRight, I suppose I forgot that a big reason `Result` works well in Rust is the `?` operator. At the very least, I'll appreciate having some more sugar over loops that are essentially just map/filter.
- tialaramex 5y agoThe ? operator wasn't in Rust 1.0 Before Rust 1.12, Rust has a macro, named try! which does a similar thing to its argument although the built-in operator has some fancier features.
- topspin 5y ago"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 agoEarly 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 agoI 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 agoI 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 agoFor what it's worth I really like how go handles errors.
- shakezula 5y agoI’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 agoeh 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.
- camkego 5y agoWas the try() proposal for Go error handling? I'm really curious what happened to the proposals for shorter Go error handling, rather than if err!=nil {...}
- mseepgood 5y ago> Was the try() proposal for Go error handling? Yes, it was the second proposal by the Go team for shorter error handling: https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md https://github.com/golang/proposal/blob/master/design/32437-... > I'm really curious what happened to the proposals for shorter Go error handling The community didn't like it and it was declined: https://github.com/golang/go/issues/32437#issuecomment-512035919 https://github.com/golang/go/issues/32437#issuecomment-51203...
- infogulch 5y agoGenerics took several iterations from the Go team to finally land on the current (pretty good, imo) design. I might expect error handling to also require multiple tries before it sticks. And we should probably wait for the dust to settle on generics a bit before proposing another design for error handling.
- mohanmcgeek 5y ago> How are you thinking of solving this with generics? People can now create Try or Option monads instead of returning the error. This was the one of the reasons anti generics people were anti generics
- mseepgood 5y agoBut that will make error handling more verbose.
- stouset 5y agoSpeaking as a user of languages that have exactly this, it can’t possibly be any worse than the situation in Go right now.
- mseepgood 5y agoOther languages have an additional zoo of language syntax besides generics to make monadic error handling bearable, which Go doesn't have.
- EdwardDiego 5y agoWill it? I can't see it myself, but happy to educate myself.
- mohanmcgeek 5y agoIt'll make it unmanageable by hiding complexity. But more verbose? I'm not so sure.
- mseepgood 5y agoPassing a single anonymous function is already more characters to type than if err != nil {}.
- johnisgood 5y agoI want the "if err != nil" back!
- mseepgood 5y agoI don't see how it changes error handling. To implement a generic error handling function you would need a non-local return statement (panicing is not error handling). And a generic monadic Result type would make error handling more verbose due to its reliance on closures for subsequent actions.
- EdwardDiego 5y agoThis is why Java went with type erasure...