This flag is what set off my thought process:
-log_backtrace_at value when logging hits line file:N, emit a stack trace
I really needed this feature for the ticket I was working on, but it's not a feature I've seen in other logging libraries.
glog takes the stance that logging should be global. You import the
glog library and log whatever lines you need wherever you want. You don't configure
glog with code, you configure it at runtime with flags. That's why glog requires you to run
flag.Parse() before using it.
glog gets the job done quickly as a global logger.
On the opposite end of the spectrum, you have logging as a proper dependency. The logger is a parameter to your function or exists on the struct. Either way, it's configurable via code which makes writing unit tests a lot easier. You don't have to resort to Go's testable examples to make sure your application is logging correctly. This approach is good when you rely on the output to be a certain way or depend on logs for more than just debug output. Check out logrus for a nice library that is easily wrapped to be a proper logging dependency.
As is the answer of almost every tech question, choose the method that works for the project at hand. Likely you'll end up somewhere in the middle and use both types of logging and that's ok. The only important thing is to treat each log type as it should be treated. So go ahead and skip unit testing of global loggers and don't forget to build in extra time for a well tested library by injecting the logging dependency.