I like that errors are in your face too, but with the caveat that only when they matter. And in Go, the lazy thing will result is a bad time. You can always bet on people being lazy.

Like take a look at this pattern:

    err := db.Get(&latLong, "SELECT lat, long FROM cities WHERE name = $1", name)
    if err == nil {
     return latLong, nil
    }

    latLong, err = fetchLatLong(name)
    if err != nil {
     return nil, err
    }

    err = insertCity(db, name, *latLong)
    if err != nil {
     return nil, err
    }

Is it really necessary to have the error handling explicit in this case? Go through any of your go code. I find this kind of error handling is 90% of the error handling I write.

Only one of the calls in the block is an actual irrecoverable error that you should propagate up to the parent caller.

If you just append if err != nil blocks everywhere without reasoning about the context you're probably doing it wrong.

If those calls can cause errors, then yes, it's necessary to handle them. Maybe you're content to have a contextless stack trace printed whenever things fail, but I like a little order.

No, it isn't necessary. Most go projects implement error handling functions, so you only have single error lines:

Handle(err)