3 ms·

I almost always instrument all my code with logging messages for the purpose of local development. Sometimes it can be very inconvenient for different reasons t

I almost always instrument all my code with logging messages for the purpose of local development. Sometimes it can be very inconvenient for different reasons to run something in the debugger, and so generating log files while running the code to test it helps me identify a lot of issues that I may have overlooked or that otherwise come up in the code while it's still being worked on. I almost never remove those log messages either, but thanks to the magic of log levels, I don't have to. Anything debug or trace level can be skipped in production logs unless we need to turn on those levels due to bugs that are commonly hit in production yet difficult to diagnose.

lawrjone 5y ago
That all sounds very normal to me, and it's what I'd expect most people do. The bit that surprised me is more likely due to my background being mostly Ruby/similar based, which is around debugging highly concurrent apps. Our app spins up goroutines all the time. One request will fan out to a number of concurrent threads, doing things like hydrating responses from Slack to syncing issue tracker tickets. With your STDOUT logs, that's so difficult to understand as it's all interwoven. And picturing all the threads and how they interact is fairly difficult. I think that's why this was such a "ah-ha!" moment for us. Suddenly we could find the "error" log in our terminal, then click the trace URL and see everything in context. That's probably the key difference to our past experience, that the app we're working with is so concurrent.