> It’s something 100% of go users have to deal with in almost every single function call. There is something clearly special about it. I can't help but feel th

> It’s something 100% of go users have to deal with in almost every single function call. There is something clearly special about it. I can't help but feel there is an even greater generalization here. The error problem you speak of actually applies to every type. To zoom in on errors alone may be missing the forest for the trees. It seems what is special is the need to handle values returned by a function, which includes, but is not limited to, error values. It is something 100% of Go users will have to do almost every time they call a function. Even those which do not return errors. > Swift and Rust have a perfect error handling mechanism. Within their respective languages they may be a good fit, but those languages are producer centric. Go is consumer centric. That leaves an impedance mismatch. I do think there is something better out there for Go, but I'm not sure that is where we are going to find it.