I am making this comment in this good faith striving not to be dismissive. The alternative proposals here look a lot like when a freshman colleague of mine deci

I am making this comment in this good faith striving not to be dismissive. The alternative proposals here look a lot like when a freshman colleague of mine decided that Go error handling is broken and wrote a custom mechanism using `panic` and `recover` that was near impossible to read and maintain. Truth is that the canonical way of handling errors in Go, despite looking unsightly to people from other language ecosystems and seeming cumbersome to use, actually works well in practice. The fact that when used along with a linter that enforces error handling, I never have to worry if a certain function I'm using can `throw` and not having to wonder whether that has been handled in a try-catch provides a lot of cognitive relief. I say this as someone who loves other languages like Rust as well. The fact that there is a canonical mechanism that everyone uses which you don't need to second guess, or jerry rig your own is a great net benefit. In Rust, it's the union Result type, in Go it's every function returning error. I would not advocate for one trying to shoehorn the other's mechanism into its own ecosystem.