Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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


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



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


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


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


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


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.


No, it only executes when you enter the err != nil block so it's almost never called, again 0 impact on performance.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: