[tgsovlerkhgsel]

No, it doesn't get any better when the codebase is bigger. The way to figure out WTF went wrong in a large code base written in Go is:

1. Take the line number where the error was logged, likely somewhere very close to e.g. the main event handling loop, and completely disconnected from the place where the error was initially thrown. There is no stack trace.

2. Try to figure out which parts of the error string are constant (i.e. searchable), and pray for the developer to have been familiar with the issue so that the string is globally unique (corollary: When writing Go, make sure your error strings are unique, introduce some form of variation if you're throwing similar errors, even if it's just punctuation or synonyms, to make sure the throw site is identifiable).

3. Try to guess what the flow between those two sites could have been.

The lack of proper stack traces (or even the line number where the error was thrown) on errors is one of the most insane effects of this error handling approach. (The other is hard to read code because the actual logic is hidden in 3x as much error handling boilerplate).