Error handling is not that great in either Go or Rust. It wasn't that great in Python, either, until Python standardized its exception hierarchy. That seems to be the key - get everything to use the same exception format, especially the libraries. How the error values are passed around is less important.

1 always need to spend 30 mins educating everyone on the "nil interface" on Go. Go lang is fine for small network services that do just one job but it doesn't scale up as an app programming language for large teams. It has far too many edge cases and gotchas. Also, loads and loads of boilerplate - making Java look elegant.

Error handling is such a train wreck. Manually returning an error in 2021? What were they smoking?

Explicit is better than implicit, and you can't get much more explicit than that.

Nobody wants to write or read

  PUSH EBP
  MOV EBP, ESP
  SUB ESP, 12

a thousand times a day. The best you can do is avoid screwing it up. So when you write a function in any language since 1960 it just happens. Stopping a function halfway and bubbling an error up the stack should also just happen.

I agree, although there are IMO more optimal and explicit ways to handle errors - Rust and Haskell come to mind. When dealing with a Result/Either/Maybe or some other functor, you have to acknowledge the context of the value, i.e. that the value could possibly be an error. This way the error handling is baked into the type system in a way that's hard to replicate in languages that just return error codes or exceptions.

> Explicit is better than implicit

Which just demonstrates why slogans are not a good substitute for thought.

They're good for programming a community though.

If you believe that I hope you only write in assembler

It's actually really nice to have the good quality error messages that Go encourages when something goes wrong.

If you remember to write them and propagate them...