I take it the implicit answer is that you’d log arbitrary keys in a reusable package. Let’s agree to disagree here.

And I’m not sold even at the application-level to map all possible logging situations to some fields, without a message. I think in the end you’ll end up having either too many keys or you’ll force-fit some situations in ambiguous existing keys, both unenviable alternatives to a message. I do believe a message is useful even in structured logging.

I take it the implicit answer is that you’d log arbitrary keys in a reusable package. Let’s agree to disagree here.

Sorry I wasn’t more explicit. Please read https://github.com/go-kit/kit/issues/42 for my detailed opinions on that topic. In that thread from last year I agree with your suggestion that libraries that do make the choice to log things should allow the application to inject a minimal logging implementation. Whether that is via a function or an interface isn’t that important because either can be easily adapted to the other if needed. But I agree with @NateFinch that widely reusable packages should not log anything. I think a case can be made for closed source libraries to do some logging, but I avoid it in general.

As for structured vs. Printf-style, I agree to disagree. I recognize this is a stylistic choice and there are different opinions about it. I also think it depends on the use case for logging, which is fine. I think that accepting these differences strengthens the argument that logging is an application concern and that is the basis upon which I believe that libraries should not do logging. Applications define the use case, libraries get reused across use cases.