[otabdeveloper4]

Once a Go program goes off the happy path, the only way to figure out what happened is to read the source code. (No, you cannot have a stack trace. Stack traces make junior programmers feel uncomfortable, and so Google made them verboten.)

And even then, because Go uses insane and outdated OOP practices like casting all pointers to a generic base class, even reading the source code is a exercise in frustration and rage.

[pkolaczk]

Stacktraces are not useful for end users of the program and should never be shown unless there is a bug in the program.

It is silly how many Java or Python programs display stacktraces on trivially preventable problems that are not bugs (e.g. file not found) instead of giving short human readable messages.

[otabdeveloper4]

Yeah, it's a good thing that programs never have bugs.

[pkolaczk]

I'm not taking about bugs but error handling. For bugs there are panics and they do print stacktraces. For error handling stacktraces are just noise.

[rollulus]

There’s error wrapping for adding context. Where one adds a human readable context to errors. Stack traces as I know them from the JVM world, with their line numbers and method names, seem a lot more coupled to the source code, so I’d say it’s the other way around really.

[otabdeveloper4]

I speak as a user of programs written in Go. (By junior programmers who love ""simple"" programming languages.)

Thank God I don't have to code anything in Go myself.