That's not my experience. checking for errors is completely optional. I'm probably just a bad lazy programmer that leans to hard on the compiler. I like the catch everything and then refine error handling as i get more understanding of failure modes (i'm from java, i avoid runtimeexception).

Go makes me feel like i need to understand all possible error cases for every line as i type it. I feel like i have to handle it right now, forever, or i'll forget that line can have an error. I really miss being able to gradually refine error handling, because i can rely on the compiler to remind me about all the stuff that can go wrong.

  if err != nil {
          return nil, err
  }

    if err != nil {
        return nil, fmt.Errorf("could not parse file %s: %v", path, err)
    }

I've just created a live template for that in Go, which just puts my cursor in the wrap message to pass along.

Aw, hell no! That's a very easily detectable (anti)pattern! You can scan even a very large code base for that! As noted in other comments, you should be adding some contextual information at this point.

Contrast this with having too-much magic, where you might have absolutely no trace in code left. You can't usefully search a large code base for all such relevant blanks.

Depth first, you make the happy path work, then refine error handling. Breadth first, you ensure everything is handled at every moment.

I’ll have to think about that a bit. Trivial cases don’t matter. Complex cases are more nuanced.

This is really insightful, thank you.

That's correct. I've heard people describe Go as wanting you to code the sad path first, and then backfill the happy stuff (the business logic) once the error handling is complete. This tracks to my experience. That is, when I program that way, I feel like I'm in sync with the language.

Your users probably don't think so

but for something running on a server somewhere, many inputs are beyond the user's control & the state is long-lived and fragile (if my HN or FB account gets somehow b0rked, that's a serious problem for me), so it's important to handle all possible error conditions in the best possible way. in my experience this is something exceptions make very hard to do.

(& i would still prefer explicit error handling even for front-end software, but i think the argument for exceptions is at least stronger there.)

Must(func()(val, err)) -> LogIf(func()(val, err))

Duck typing can still lead to runtime errors which is practically all accounted for thanks to the compile-time safety of structured typing.