I found the https://github.com/juju/errors library to be a very practical way to include tracing info in the error values.
I wish the core error library behaved like that, and that the core language made it less verbose.
This is a typical thing in Go: the language is kept stable and backward compatibility is king. Solutions for some things are left to the community.
Other languages changed a lot over the years, getting better but frustrating people because of breaking changes. I believe this promise of stability paved the way for much of Go's success, despite many shortcomings
> This is a typical thing in Go: the language is kept stable and backward compatibility is king. Solutions for some things are left to the community.
C++16 beta compilers can compile the very first C program just fine. How's that for backwards compatibility ? 44 years. In fact, this is exactly what's frequently blamed for C++'s complexity. Support lots of weird edge cases because "at some point it worked". Over 44 years (wtf C is old now).
Java - same. ML - same. C++ - same.
> I believe this promise of stability paved the way for much of Go's success, despite many shortcomings
Actually for most of it's 7 year life the exact opposite is true. Go regularly broke it's weird cases (I would say because getting a compiler without a sound type system working well is a road that is littered with mines). This is why "gofix" exists ( https://blog.golang.org/introducing-gofix ). Go's authors are crediting this with Go's "simpleness".
I wish the core error library behaved like that, and that the core language made it less verbose.
This is a typical thing in Go: the language is kept stable and backward compatibility is king. Solutions for some things are left to the community.
Other languages changed a lot over the years, getting better but frustrating people because of breaking changes. I believe this promise of stability paved the way for much of Go's success, despite many shortcomings