I think people are constantly focusing on the wrong target here though. The main problem of error handling in Go is not the tediousness of writing if err

I think people are constantly focusing on the wrong target here though. The main problem of error handling in Go is not the tediousness of writing if err != nil {} after each function (it's not nice but bearable). The main problem is how hard to actually process errors. In Go, there are three types of errors: custom structs with contextual info, predefined error constants of type stringError aka sentinels, and wrapped stringErrors, produced in-place by fmt.Errorf. The first ones can be matched by type coersion or errors.As function. The second ones can be compared with == operator. The last ones can be either parsed by regex, or matched by the error they wrap and then unwrapped. Oh, and the signature is nearly always just error, so basically to process errors gracefully you have to read the docs for each function instead of just looking at the signature. It's so extremely inconvenient and tedious so nearly nobody process errors in Go, despite what language creators say. People either return error to the top of the callstack, maybe wrapping it in additional string, thus emulating poor man's exceptions without stack traces, or panic in-place. Nearly nobody catches and matches errors, as many in C++, Java, Scala or OCaml|Haskell world do.