Because it’s neither horrible nor regrettable, it just doesn’t cater to your perfect idea of what it should be. It’s a smart way to encourage people to handle errors.
you think it's "smart" to encourage a large fraction of function calls to have
if err != nil {
return nil, err
}
after it? really? you don't think it's just a very simple way to do it without having to do a lot of work in the language? and then make everyone use a linter to avoid bugs? oh and you can't always literally do 'return nil, err' because strings have to be ""?
it's certainly defensible as a minimalist approach, claiming it's actually good or smart or ideal is a pretty weird take.
You think it’s “a lot of work” to write an if statement? Any of the proposed variations have shown to be either different syntax (weak valueless change) or would allow people to ignore handling errors.
You can’t always return nil? is that a complaint that you are required to do things differently for data types that require it inside of a complaint about doing things the same?
It’s not a weird take, things have tradeoffs, this is a tradeoff of using Go.
It's not a lot of work, you can just let the IDE spew it off for you and feel like a certified J2EE programmer circa 2003 who lets the IDE write everything for them. But yeah, writing code is not the problem. Reading the code is.
So then it’s less readable because you have to process a simple error return? I won’t even comment on the 60% of code is error handling, that sounds like code that needs refactoring.
More precisely because "they" are Rob Pike, and Rob Pike doesn't seem to think error handling in Go is horrible.
Other members of the Go Team (Robert Griesemer, Russ Cox) trialed out several solutions for this problem, but this issue was just too controversial within the community.
