Stack traces are, for me, too much noise, and not enough signal. I prefer reading annotations added (prefixed) by programmers deliberately. File and line information for the call stack leading to the error maybe provide value in the dev cycle (e.g. when fixing tests) but basically don't in logs in production.
This is all to say: I can understand why they aren't more naturally part of errors, and I think it also helps explain why they are part of panics.
And with all that said, I wouldn't object to making stack traces easier to add to errors, as long as it was opt-in.
Does anyone know if this was a conscious decision? I mean IIRC in Java you're generally discouraged from throwing errors for control flow because creating the stack trace is a relatively heavy process. In Go this is of less concern and returning an error is pretty normal for control flow (as in errors are expected, not exceptional), and you shouldn't have to worry that an error path would be 100x as expensive as a normal flow because a stack trace is being generated.
JMTCW, but since I generally program Go in GoLand with the debugger, I have full access to the stack all the time so I have not found this to be a major concern. But YMMV.
This is all to say: I can understand why they aren't more naturally part of errors, and I think it also helps explain why they are part of panics.
And with all that said, I wouldn't object to making stack traces easier to add to errors, as long as it was opt-in.