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.
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.
Certainly, it's still ways better than C. But the resulting boilerplate and copy-paste programming ought to be a source of errors.
(I'm happy to see the generics proposal coming closer and closer to a future feature.)