[sidlls]

I really appreciate the lack of magic in go's error handling. I do not appreciate the specific implementation of errors in go. It's inefficient (`reflect` is all over the place) and prone to obscuring the actual "error path". In applications of non-trivial size, it also becomes an obstacle to implementing structured logging and other components of observability. This makes debugging/triage of, say, a production incident harder than it needs to be.

[kbar13]

in 8 years of writing go at scale i've never used reflection in production code. gonna need an example of what you mean.

[Thaxll]

I've never seen or used reflection with error handling in Go, what do you mean?

[sidlls]

https://cs.opensource.google/go/go/+/refs/tags/go1.21.6:src/...

[derekperkins]

I wouldn't classify type assertion as reflection. It's a super fast type check of the object header, not dynamic reflection.

[Thaxll]

But this is a detail of implementation, user code does not use reflection with errors.

[sidlls]

That "detail of implementation" is what is used by user code, e.g., `myError.As(...)` uses reflection, implicitly.

[Thaxll]

Then what? It has 0 performance impact, we're talking about error handling here, it's rare and not in hot path.

[sidlls]

It does not have 0 performance impact, it's not rare, and in applications that are in the hot path, error handling is also in the hot path.