6 ms·

Eh, I feel like Go errors are a mess, personally. Though, I'm not sure how to solve them. Mind you, this is after ~5 years of use, so it's not from "an outsider

Eh, I feel like Go errors are a mess, personally. Though, I'm not sure how to solve them. Mind you, this is after ~5 years of use, so it's not from "an outsider" - I hope, at least lol. Most of blame for the mess is that the error interface throws away meaningful information. Then the caller is left mentally checking how to handle the error. Do I value check? Type cast? String check? Does the library expose a function to check, or do I do it myself? Can I get stack traces in some cases without introducing a production cost? I'm not sure if Go needs a different type of error interface (ie diff methods), or if it needs Generics to solve this properly in my view. But, I just know I've hated the experience. After I switched to Rust it all felt so familiar, and yet so different. I believe Rust and Go share error patterns. Yet in Rust I'm never left wondering what an error is, what I should do with it, how I check for specific types. This is largely due to awesome enum support and of course generics. Does Go need this feature set to "fix" my complaints with errors? Probably not.. but I do think it needs something. Though I will agree, I don't think the `if err != nil` is fundamentally the problem with Go's errors, at all. Sure, the UX could be improved, but that's another story all together imo.

hermitdev 7y ago
Honest question as a non Go user: how would generics (from a C# perspective) help? I assume that Go generics would be analogous those in C#. Edit: spelling, genetics to generics.
- Nullabillity 7y ago
  Rust has a wrapper type `Result<ReturnType, ErrorType>`[0] that essentially works the same was as Go's `return value, err` idiom, but is safer because the type is defined so that you can't access the returned value unless you also handle the error condition, and it can have a convenience syntax for chaining since it is a dedicated unambiguous type. The compiler also specifically warns you about unused `Result`s, to avoid unhandled errors, and the API is structured so that nonsensical states such as `(nil, nil)` or `(value (!= nil), error (!= nil))` are impossible (unless specifically opted into). Without generics you would have to either throw away the type information, reimplement a `Result` type for every value type, or copy/paste the implementation at each usage site (the common Go pattern). Go's support for multiple returns itself is also a hack around the lack of support for tuples (which would be trivial to implement if you had generics). [0]: https://doc.rust-lang.org/std/result/enum.Result.html https://doc.rust-lang.org/std/result/enum.Result.html
  - mappu 7y ago
    > a hack around the lack of support for tuples (which would be trivial to implement if you had generics) To a first approximation, the purpose of Go is to stop every codebase from reinventing its own tuples or Result<> type. Go does have generics, the Go compiler could add a chaining syntax for trailing err interfaces (like rust ? / try!) without needing to allow user-defined generic types.
    - mrgriffin 7y ago
      I hope it's not literally to prevent people reinventing these simple data structures. The ecosystem exerts a lot of pressure on developers to not reinvent fundamental things, in Haskell I practically never reach for a StrictTuple or StrictEither even when I'd like strictness specifically because they are clunkier and less well integrated with other libraries. Scala is the only language that comes to mind with this issue (scalaz vs Cats) and my impression is that even they have mostly converged. I would say Go has much stronger idioms than either of these languages, and wouldn't need to be afraid of people inventing their own fundamental types provided they're included in the standard library.
      - majewsky 7y ago
        > Scala is the only language that comes to mind with [the issue of needlessly reinvented fundamentals] C/C++ is another example. There are a plethora of string types mostly tied to which base set of libraries you're using. If you're using the C++ stdlib, you have std::string. But if you're using Qt, you're using QByteArray and QString instead. And probably similar for GLib/GTK. (Does std::string even have any encoding support yet? When I last used it, it was just a string of bytes without any encoding awareness.)
    - asdkhadsj 7y ago
      > To a first approximation, the purpose of Go is to stop every codebase from reinventing its own tuples or Result<> type. Rust has this too. You can throw away type information and incur a runtime cost just like with Rust by using "Trait Objects", which are Rusts version of interfaces, basically. Luckily most choose not to use this for error communication. However I struggle to understand that throwing type information away and incurring runtime cost is the pinnacle of error communication. Furthermore, the idea that this somehow prevents codebases from "reinventing" anything is absolute nonsense. Basically every Go lib out there has different error handling. Hell, I wrote a library of my own (similar to pkg/errors). The very items I listed in my OP showed how every lib has it. You have no idea how each Go lib reinvented the wheel to know how you handle their errors. All with runtime checking. Madness.
pixelrevision 7y ago
I really think how you are using the language had a large effect on how you are going to view all this. If you are building a commandline utility then the way go deals with errors is great you just panic and send back a message. If you are building a long running web service you want a whole lot more info to go into your logs for when things go wrong. I dunno what the solution is but try/catch doesn’t seem to be the right thing to focus on.
- eloff 7y ago
  Despite the name, there's really nothing in common with try/catch. It's just sugar for if err != nil { return }.
  - pfarnsworth 7y ago
    Try is a terrible choice for a name exactly because of try/catch, I don't know why they decided on that.
apta 7y ago
> so it's not from "an outsider" - I hope, at least lol. I used golang at an employer and you're right, it's a huge mess (and error handling is just one part of it).
- asdkhadsj 7y ago
  It's a shame too. The language is actually quite nice. They made a lot of decisions that simplify and improve code quality, large code bases, etc. However a few decisions are huge signals that they didn't really think through them. Error handling and the now-solved package management are two big ones.
  - apta 7y ago
    > They made a lot of decisions that simplify and improve code quality, large code bases, etc. I keep seeing those claims (e.g. "programming in the large"), but in my experience, practically all the decisions in the language make it more awkward and difficult, even unnecessarily so, to deal with large code bases. golang's interfaces for instance, are optimized for a small use case, at the expense of them being useless for actually useful things, like tagging and fast code search. The way "methods" are assigned to structs is overly verbose, and makes it easy to have to jump around even several files to figure out all functions that are tied to a struct. The list is too large to list here.
    - asdkhadsj 7y ago
      So, in the large codebases I've been a part of I think Go makes it easier.. BUT, it's an asterisk "easier*". The asterisk being I think it's easier to reason about Go projects, large and small, in a "local sense" only. That is to say, I think you can wander around Go code with less context on the whole project and have a better idea on what that tiny piece of code is doing. Compared to my Rust code bases, I feel like you need a larger picture of the project to understand what smaller code pieces do. Is that a good thing though? Not sure, honestly. Should I really feel I understand what a function does, without understanding the functions role on the project itself? How can I truly understand a function without understanding its role? Go feels like it's easier to understand the implementation, but not the context/purpose. Arguably, this may not be good. I still prefer Rust, fwiw.
praseodym 7y ago
There is an ‘error inspection’ proposal for Go 2.0 which will hopefully solve this issue: https://go.googlesource.com/proposal/+/master/design/go2draft-error-inspection.md https://go.googlesource.com/proposal/+/master/design/go2draf... The proposal has been partially accepted and implemented in Go 1.13: https://github.com/golang/go/issues/29934#issuecomment-489682919 https://github.com/golang/go/issues/29934#issuecomment-48968...

hermitdev 7y ago

Honest question as a non Go user: how would generics (from a C# perspective) help? I assume that Go generics would be analogous those in C#. Edit: spelling, genetics to generics.

Nullabillity 7y ago
Rust has a wrapper type `Result<ReturnType, ErrorType>`[0] that essentially works the same was as Go's `return value, err` idiom, but is safer because the type is defined so that you can't access the returned value unless you also handle the error condition, and it can have a convenience syntax for chaining since it is a dedicated unambiguous type. The compiler also specifically warns you about unused `Result`s, to avoid unhandled errors, and the API is structured so that nonsensical states such as `(nil, nil)` or `(value (!= nil), error (!= nil))` are impossible (unless specifically opted into). Without generics you would have to either throw away the type information, reimplement a `Result` type for every value type, or copy/paste the implementation at each usage site (the common Go pattern). Go's support for multiple returns itself is also a hack around the lack of support for tuples (which would be trivial to implement if you had generics). [0]: https://doc.rust-lang.org/std/result/enum.Result.html https://doc.rust-lang.org/std/result/enum.Result.html
- mappu 7y ago
  > a hack around the lack of support for tuples (which would be trivial to implement if you had generics) To a first approximation, the purpose of Go is to stop every codebase from reinventing its own tuples or Result<> type. Go does have generics, the Go compiler could add a chaining syntax for trailing err interfaces (like rust ? / try!) without needing to allow user-defined generic types.
  - mrgriffin 7y ago
    I hope it's not literally to prevent people reinventing these simple data structures. The ecosystem exerts a lot of pressure on developers to not reinvent fundamental things, in Haskell I practically never reach for a StrictTuple or StrictEither even when I'd like strictness specifically because they are clunkier and less well integrated with other libraries. Scala is the only language that comes to mind with this issue (scalaz vs Cats) and my impression is that even they have mostly converged. I would say Go has much stronger idioms than either of these languages, and wouldn't need to be afraid of people inventing their own fundamental types provided they're included in the standard library.
    - majewsky 7y ago
      > Scala is the only language that comes to mind with [the issue of needlessly reinvented fundamentals] C/C++ is another example. There are a plethora of string types mostly tied to which base set of libraries you're using. If you're using the C++ stdlib, you have std::string. But if you're using Qt, you're using QByteArray and QString instead. And probably similar for GLib/GTK. (Does std::string even have any encoding support yet? When I last used it, it was just a string of bytes without any encoding awareness.)
  - asdkhadsj 7y ago
    > To a first approximation, the purpose of Go is to stop every codebase from reinventing its own tuples or Result<> type. Rust has this too. You can throw away type information and incur a runtime cost just like with Rust by using "Trait Objects", which are Rusts version of interfaces, basically. Luckily most choose not to use this for error communication. However I struggle to understand that throwing type information away and incurring runtime cost is the pinnacle of error communication. Furthermore, the idea that this somehow prevents codebases from "reinventing" anything is absolute nonsense. Basically every Go lib out there has different error handling. Hell, I wrote a library of my own (similar to pkg/errors). The very items I listed in my OP showed how every lib has it. You have no idea how each Go lib reinvented the wheel to know how you handle their errors. All with runtime checking. Madness.

pixelrevision 7y ago

I really think how you are using the language had a large effect on how you are going to view all this. If you are building a commandline utility then the way go deals with errors is great you just panic and send back a message. If you are building a long running web service you want a whole lot more info to go into your logs for when things go wrong. I dunno what the solution is but try/catch doesn’t seem to be the right thing to focus on.

eloff 7y ago
Despite the name, there's really nothing in common with try/catch. It's just sugar for if err != nil { return }.
- pfarnsworth 7y ago
  Try is a terrible choice for a name exactly because of try/catch, I don't know why they decided on that.

apta 7y ago

> so it's not from "an outsider" - I hope, at least lol. I used golang at an employer and you're right, it's a huge mess (and error handling is just one part of it).

asdkhadsj 7y ago
It's a shame too. The language is actually quite nice. They made a lot of decisions that simplify and improve code quality, large code bases, etc. However a few decisions are huge signals that they didn't really think through them. Error handling and the now-solved package management are two big ones.
- apta 7y ago
  > They made a lot of decisions that simplify and improve code quality, large code bases, etc. I keep seeing those claims (e.g. "programming in the large"), but in my experience, practically all the decisions in the language make it more awkward and difficult, even unnecessarily so, to deal with large code bases. golang's interfaces for instance, are optimized for a small use case, at the expense of them being useless for actually useful things, like tagging and fast code search. The way "methods" are assigned to structs is overly verbose, and makes it easy to have to jump around even several files to figure out all functions that are tied to a struct. The list is too large to list here.
  - asdkhadsj 7y ago
    So, in the large codebases I've been a part of I think Go makes it easier.. BUT, it's an asterisk "easier*". The asterisk being I think it's easier to reason about Go projects, large and small, in a "local sense" only. That is to say, I think you can wander around Go code with less context on the whole project and have a better idea on what that tiny piece of code is doing. Compared to my Rust code bases, I feel like you need a larger picture of the project to understand what smaller code pieces do. Is that a good thing though? Not sure, honestly. Should I really feel I understand what a function does, without understanding the functions role on the project itself? How can I truly understand a function without understanding its role? Go feels like it's easier to understand the implementation, but not the context/purpose. Arguably, this may not be good. I still prefer Rust, fwiw.

praseodym 7y ago

There is an ‘error inspection’ proposal for Go 2.0 which will hopefully solve this issue: https://go.googlesource.com/proposal/+/master/design/go2draft-error-inspection.md https://go.googlesource.com/proposal/+/master/design/go2draf... The proposal has been partially accepted and implemented in Go 1.13: https://github.com/golang/go/issues/29934#issuecomment-489682919 https://github.com/golang/go/issues/29934#issuecomment-48968...