It looks like at least one popular public tool, panicparse, depends on the current format. Not to mention private tools that may also depend on the current format. Technically, the format doesn't seem to be subject to Go1 compatibility since it would probably fall under "Unspecified behavior" - I don't see any mention of panic dump format in the spec. However, since this doesn't seem so critical, we should probably hold off until Go2 so we don't needlessly break existing tools.

(@ianlancetaylor based on my reasoning, do you think this should be tagged with Go2?)

I think we should close this issue.

I don’t think reversing the order of a stack trace is useful for two reasons.

1. The most useful place for a stack trace is in reporting a bug in production. In which case, the current behaviour, the faulting goroutine at the top of the stack trace and the faulting line directly following the panic message is optimal.
2. Reversing be order of a goroutines stack trace is optimising for the simple case — no cocurrency. Reversing the ordered of printing stack frames would mean the faulting goroutine is (probably) the first one printed but the faulting line is in the middle of the stack trace.

I think you'll see way more stack traces while developing and testing locally than in actual production. Obviously in the first scenario errors are unavoidable and commonplace, in the latter I would hope they're not. Certainly they're more important when they happen in production. But the principle of optimizing for the more common development case would seem to be the best. This is a proposal for a feature to save developers time, and that yields the biggest benefit when multiplied by the largest number of times invoked.

To be clear I don't think we should optimize for the no goroutines case. I don't know how many errors involve multiple goroutines, but I expect it's a large quantity given that's one of the main features of the language. My experience in the industry suggests the same.

Putting important information at the top means it will be above the fold with short terminals or large stack traces, which is also probably most of the time. For example that little tiny integrated terminal at the bottom of vscode that most people use. So I'll boil this down to one question:

Is there any summary information that's usually important in determining what went wrong and where, that we could place at the very bottom of the output (even if it duplicates information) so that panics can be diagnosed in many cases without having to scroll up and pore over the stack traces?

For example, the panic message and the file name and last line in user code code (that is not inside the stdlib or the vendor directory) from the goroutine that had the panic. The rest of the output can stay unchanged, my proposal would only add one lor two lines of additional, duplicated information. Short, succinct, and almost universally what you need to see to take action in diagnosing the problem. Just having that next step in front of you is great for ADD types like me that see a big giant blob of stack traces and get distracted trying to figure out what the next step is.

Thoughts?