https://go.dev/blog/error-syntax
tl;dr - proposals are no longer being considered
Hot take, maybe, but this is one of the few "mistakes" I see with Go. It makes adding QoL things like you mentioned difficult, requires shoehorning pointers to allow for an unset condition, some types don't have a safe default/zero value like maps, and makes comparisons (especially generic) overly complex.
... So what? From what I can tell that's all anyone has asked for in the context of something to just return nil/error up the call stack.
data, _ := os.ReadFile(path)
Saying that is not explicit is just wrong.
cryptos•1h ago
sheept•17m ago
But this makes the language feel like Python, in some ways. Besides nil, the lack of expressivity in its expressions makes it more idiomatic to write things imperatively with for loops and appending to slices instead of mapping over the slice. Its structurally typed interfaces feel more like an explicit form of duck typing.
Also, Go has generics now, finally.
andriy_koval•9m ago
disagree, they made many decisions which are different from mainstream: OOP, syntax as examples.
antonvs•15m ago
I'm not convinced that you couldn't have good software engineering support and simplicity in the same language. But for a variety of mostly non-technical reasons, no mainstream language provides that combination, forcing developers to make the tradeoff that they perceive as suiting them best.