3 ms·
The problem is, it's not one dependency. Several important libraries pull in a variety of wrappers and adapters - just to name three: - glog (gRPC) - logr (Op
by jen20 4y ago
The problem is, it's not one dependency. Several important libraries pull in a variety of wrappers and adapters - just to name three:
- glog (gRPC)
- logr (OpenTelemetry and friends)
- klog (Kubernetes client)
It's quite conceivable that even having decided to use zerolog, you end up with at least four separate logging libraries in your dependency tree before having written any of your own code.
- latchkey 4y agoTrue, but as long as I can either control the logging or write an adapter, I'm ok with that. At the end of the day, I'd still have that issue, unless the standard lib was being used everywhere... which is something that is equally not controllable.
- jen20 4y agoThe hope of a standard structured logging interface in the standard library is that serious libraries will adapt themselves to use it, and the proliferation will disappear over time. Whether or not this will actually happen, or whether the libraries which do not play ball will have to be forked is a different matter.
- latchkey 4y ago"serious" libraries today all provide the ability to pass in adapters. Having been in the group of a multi-year effort to do this in Java (JSR-47), there is always a limitation in the API that prevents someone from getting it right. Funny enough, even though Java ended up with JUL (java.util.logging), SLF4J ended up being the defacto standard that everyone went with.