[arccy]

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.

[marginalia_nu]

I think that's a bit unfair. Generally the stacktraces tell you exactly what and where the problem is. Generally shouldn't be more than a dozen lines or so.

The main area they get excessively lengthy is in certain frameworks and testing tools that can add like 100 lines to the trace.

[frontfor]

Compared to Go where I always have to remember to print the stack trace in every goroutine’s panic handler or use a custom error type that includes the stack trace or I get nothing? And I have to do this very basic thing for every service I spin up? This might not matter for pet projects or CLI applications, but it matters a lot in large scale mission critical servers.

[lenkite]

Tip of the Day: You can wrap errors using "fmt.Errorf" in Go - this gives you a nice chain of error messages which is a pseudo stack trace. Another tip is to define and leverage sentinel errors when wrapping errors so you can test using "errors.Is" higher up when doing error handling in the call-hierarchy - like when mapping to http errors or exit codes.

Using "fmt.Errorf" is lean and painless compared to defining custom errors.

[homebrewer]

And be very careful in constructing your error messages so that grepping the error string does not return you 50 matches. It's not the same as getting the error message + file name + line number.

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.

[dontlaugh]

It’s still not stack traces for every error, which is the default in every other language with stack unwinding.

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.

[jjav]

> stacktraces where you need 3 vertical monitors stacked together

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.

[int_19h]

This is unfortunately common across most ecosystems today. Such lengthy stack traces are routine in JS, and fairly common in C++.

[hu3]

as someone who had to deal with Java stack traces the entire week, I feel attacked.

God bless Gemini 2.5 Pro which ate all the traces for breakfast.