The issue with the approach in Go is not that the errors need to be handled from each call. The issue is the language is inexpressive, overly verbose and forces massive amounts of duplicated code for this. It doesn't have a way to return a result or an error or to work with that.
Conversation
It forces always returning both a result and an error, and it does that via a hard-wired multiple return value feature rather than a type like a tuple which would lend itself to less code repetition. Avoiding exceptions doesn't imply having this kind of verbosity / repetition.
2
2
Replying to
It seems like returning a tuple would also result in a lot of repetitive code to unpack and check the error value from it. What would that look like?
1
Replying to
Returning a tuple is also a bad implementation, because you don't actually want to return the result and the error, but rather either the result or the error. It would still be much better than the special-cased multiple return value since you can actually have code reuse for it.
1
4
As in you can write functions / methods taking (ResultType, ErrorType) and compose them together. Of course, that's not going to work very well without the ability to write code that's generic across types, which is tied into this too. Go is quite hostile towards code reuse.
2
4
Replying to
It seems like a consequence of core decisions about the type system (e.g. not supporting algebraic data types). I'm not sure if I'd agree that it's hostile to code reuse, you just have to reuse at a higher level of abstraction (libraries).
1
2
Replying to
It doesn't have good support for reuse via libraries since in so many cases it forces writing specialized code or use the awful hack of reflection and dynamic casting. In that sense it's a lot like Java before it had half-baked generics. I wouldn't call these conscious decisions.
1
1
To be a conscious decision, they would have needed an understanding of the other design choices and experience with them. It's clear they didn't. The decisions would make some sense in a world where only terrible type systems and generics like the ones in Java and C++ existed.
1
5
Replying to
I wouldn’t presume that they were unfamiliar, but instead chose simplicity of compiler implementation over other approaches. There are many cases where there are trade-offs between simplicity of implementation vs. interface and the Go authors come from a philosophy of the former.
1
1
1
Replying to
I don't think Go has simple or minimal language design. It has a lot of special cases and hard-wired solutions to problems, rather than elegant features fitting together well. It's the opposite of having small, reusable solutions to problems like composability of *nix utilities.
The spirit of Go is hard-wiring special-cased features into the language, in a way that programmers cannot implement themselves. The Go designers can make generic types like arrays, slices and maps, but you can't. They can do product types (multiple return values), but you can't.
1
2
10
It's hostile towards code reuse and programmers. It's deliberately bad, and aimed at what they think fits the lowest common denominator, but I don't think it succeeds at that. The language not providing solutions doesn't make the problems go away. Sometimes worse is just worse.
1
5
9
Show replies