Readability absolutely suffers when almost everything you see on your screen is boilerplate.

Seriously. I see so many functions in my code see that consist of 1 line of thing I actually care about followed by 3 lines of boilerplate if err not nil… over and over again.

IMO if Go didn’t have its tooling, no one would care about it.

i have the completely opposite take.

every if err != nil; return err let's me mentally draw a line in the sand and not worry about exception handling for code above that line. It lets me start fresh and restart my mental model with the line of codes below the error handling block.

it doesn't take years of writing Go to understand this, all you need is a open mind to how Go does things.

> It lets me start fresh and restart my mental model with the line of codes below the error handling block.

My code is almost exactly:

err := doThing()

if err != nil {

  return err

}

err = doAnotherThing()

if err != nil {

  return err

}

etc.

There's no need for me to "start fresh". Each line of actual stuff doing might return an error which needs to be returned. That's it. It's a complete waste of space and inhibits readability to absolutely no benefit. And this is extremely common across our code base.