funny. java is known for its stacktraces where you need 3 vertical monitors stacked together to see the whole thing and it still doesn't tell you anything useful about why the app crashed.
The main area they get excessively lengthy is in certain frameworks and testing tools that can add like 100 lines to the trace.
Using "fmt.Errorf" is lean and painless compared to defining custom errors.
In practice you have to use a combination of error wrapping and custom stack trace errors for your production logs to be useful on failure. The stdlib errors really should have stack traces.
This is the whole story of Go, they pick something established and reimplement a heavily cut down version of it for "reasons", then slowly catch up to competition over the next decade or so.
If you wrote code with such deep stacktraces, it's all on you.
There's a performance cost to all that excessive stack depth too, often.
God bless Gemini 2.5 Pro which ate all the traces for breakfast.