Errors are different in every stdlib or 3rd party package I've ever used.
The ecosystem as a whole decided that errors should be useful, values, and properly bubbled up - and that your application should not be so hard to reason about that you need a stack trace to know where in the deep recesses of your code something went wrong.
I love stack traces in Java, but I don't miss them at all in Go.
Go's development process is fairly open and democratic though; if enough people flag it up, and if a case can be made for stack traces, it can be added.
As it stands though, the consensus is that it doesn't add enough value, it's too expensive (cost/benefit), errors are normal program flow, and 3rd party libraries can add the functionality if one decides they need/want it in their application.
"your application should not be so hard to reason about that you need a stack trace to know where in the deep recesses of your code something went wrong."
Curious how Go is better than other languages in this regard.
That quote isn't about Go specifically though, but about general application design. It seems to be a subtle snipe that languages with stacktraces like Java, C# are too complicated or have too many layers ("lasagna code"), making them more difficult to debug.
The ecosystem as a whole decided that errors should be useful, values, and properly bubbled up - and that your application should not be so hard to reason about that you need a stack trace to know where in the deep recesses of your code something went wrong.
I love stack traces in Java, but I don't miss them at all in Go.