3 ms·

> nightmarish manual type discovery Your criticism here is of a lack of Sum-types in Golang, not the approach to errors as values. It's just a different philos

> nightmarish manual type discovery Your criticism here is of a lack of Sum-types in Golang, not the approach to errors as values. It's just a different philosophy to Rust. Go maintains a strict backwards-compatibility guarantee (*love* this), and using sum types for errors would mean, at least in the stdlib, either (a) no new errors can be introduced, or (b) new versions of Go would break builds when new errors are introduced. > Since the some function may just return an error interface, there's > no way for the end user to know you've added that error type. From > their prospective, everything is unchanged, and still compiles just fine. Personally, I value my code compiling in the future over more explicit error handling. New errors will hit my catch-all branch, and I can special-case them later as I see fit. But it's a philosophy/values thing. As an aside, I very rarely find myself actually wanting a sum type for errors. I usually want to check for a few specific errors, but I almost always want a catch-all for truly unexpected stuff. Sum typed errors in any complex system often end up needing a `.other()`-style case anyway because in the real world so much can go wrong. Rust is by no means perfect either. The `?` operator steers you in the direction of ignoring errors rather than thinking about them, which I think leads to worse outcomes (i.e. that Cloudflare outage)

nirui 9mo ago
I think we've wasted a lot of time on this. > Personally, I value my code compiling in the future over more explicit error handling. New errors will hit my catch-all branch, and I can special-case them later as I see fit. But it's a philosophy/values thing. OR, you can just do `fn() MyError` then `if myError := fn(); !myError.OK()` opposite to just `fn() error`. I actually use this "trick" on many of my projects and they worked great. I'm not really sure why Go defenders MUST praise Go's error handling as if it's flawless and thus all fault signals must be a `error`. As I pointed out few comments back, Go is clearly promoting binary error handling i.e. `if err != nil { return error }`, as doing branched out handling for specific error type is much harder (one example is the "nightmarish manual type discovery" mentioned above), so it's far from flawless. It's useful, sure, and people are using it, but it's not flawless. BTW: > I can special-case them later as I see fit See? You already doing manual type discovery, they slipped the idea so naturally into your brain you don't even notice the struggle. But what if the number of types that you need to take care of keeps growing? Is it scalable? You know what, maybe they should add Sum type for error handling. Hope it's not too late now since many people already camped on the idea that returning an interface then and casting it for error handling is the best idea ever.

nirui 9mo ago

I think we've wasted a lot of time on this. > Personally, I value my code compiling in the future over more explicit error handling. New errors will hit my catch-all branch, and I can special-case them later as I see fit. But it's a philosophy/values thing. OR, you can just do `fn() MyError` then `if myError := fn(); !myError.OK()` opposite to just `fn() error`. I actually use this "trick" on many of my projects and they worked great. I'm not really sure why Go defenders MUST praise Go's error handling as if it's flawless and thus all fault signals must be a `error`. As I pointed out few comments back, Go is clearly promoting binary error handling i.e. `if err != nil { return error }`, as doing branched out handling for specific error type is much harder (one example is the "nightmarish manual type discovery" mentioned above), so it's far from flawless. It's useful, sure, and people are using it, but it's not flawless. BTW: > I can special-case them later as I see fit See? You already doing manual type discovery, they slipped the idea so naturally into your brain you don't even notice the struggle. But what if the number of types that you need to take care of keeps growing? Is it scalable? You know what, maybe they should add Sum type for error handling. Hope it's not too late now since many people already camped on the idea that returning an interface then and casting it for error handling is the best idea ever.