<p>Just curious why the log package does not expose an interface for logging allowing us to implement custom logging logic with a standard interface.</p>
<hr/>**评论：**<br/><br/>kardianos: <pre><p>No one seems to be able to agree what such an interface should look like. There was a golang-dev thread about just this.</p></pre>tophermck: <pre><p>Is this the discussion you are referring to? <a href="https://groups.google.com/d/msg/golang-dev/F3l9Iz1JX4g/szAb07lgFAAJ" rel="nofollow">https://groups.google.com/d/msg/golang-dev/F3l9Iz1JX4g/szAb07lgFAAJ</a></p></pre>shazow: <pre><p>Indeed, and the <a href="https://docs.google.com/document/d/1nFRxQ5SJVPpIBWTFHV-q5lBYiwGrfCMkESFGNzsrvBU/edit">accompanying proposal document</a>.</p>
<p>It seems that if we go too general then we're left with <code>io.Writer</code> and if we go too specialized then too few use cases are satisfied. </p>
<p>Maybe logging is one of those things that does not need to have a more general interface. The sweet spot is what we have already, and everything else is case-by-case.</p></pre>titpetric: <pre><p>What would be the problem with providing an io.Writer with extended functionality? You can wrap any additional parameters/etc. into a function or closure that returns an io.Writer, something like <code>func KafkaLogWriter(c *KafkaConfig) io.Writer { ...</code>, no?</p></pre>Veonik: <pre><p>io.Writer doesn't capture context, for one. A line of text in your log is less useful than a line of text with a bunch of metadata describing what and where the line of text is talking about. Then there are different logging levels. You could, of course, typify these things like you're saying by creating a specific Logger for each service (so it includes context for itself when calling Write) and a specific Logger for each log level. But I'm not sure that is a good way to go, either. It would make application-wide changes to logging pretty unpalatable.</p></pre>xienze: <pre><p>Correct answer. Look at Java, there's been a standard logging library just about forever and yet there's still tons of 3rd party loggers available. Logging is one of those things you'd think wouldn't be controversial, but it totally is. You're never going to get everyone on board with a standard logging API, so I don't really blame the Go devs for staying out of this.</p></pre>thockin: <pre><p>IMO, this is a desperately missing facet of the stdlib. For lack of it, everyone has invented their own, meaning no two libraries can share any sort of logging without adapters or hard dependencies. Puke.</p>
<p><a href="https://github.com/go-logr/logr">https://github.com/go-logr/logr</a></p></pre>tophermck: <pre><p>I agree 100%, I don't see a reason why the log package couldn't just expose an interface which matches its Logger it is a simple logger that matches (in most cases) best practice for logging, and by that I mean not having too many types of logs.</p></pre>ooesili: <pre><p>I agree that a standard library interface would be useful, but at the same time I feel like <em>libraries</em> have no business doing their own logging.</p></pre>fortytw2: <pre><p>libraries should present good diagnostic interfaces, like <code>net/http/httptrace</code>, then the end user can "log-to-stdout" or do whatever they want with that information.</p></pre>thockin: <pre><p>There are many things that have been made easier for me by having logs close to the source of an occurrence. I just have to disagree.</p></pre>: <pre><p>[deleted]</p></pre>titpetric: <pre><p>Not sure i agree about flag, it seems to have a well defined api thats implemented by namsral/flag, pflag and other flag packages that add config files, environments and so on. As a basic implementation I don't see flag being a pain point. Sure, viper (or something better) add additional configuration mgmt functionality, but it's an apples/oranges comparison at that point.</p>
<p>It would be interesting to check what the PHP-fig came up in the PSR for logging and how it compares to golang log package.</p></pre>carsncode: <pre><p>You can. Because interface implementation in Go is implicit, interfaces are better defined where they're used, not where concrete implementations are defined. Since nothing in the standard library takes a logger, there's no need for a logger interface there.</p></pre>PatrickTheHoss: <pre><p>If there was a standard logger interface, vendor libraries could code against that and an implementation of that interface would be reusable across libraries.</p></pre>carsncode: <pre><p>Libraries shouldn't be logging though. If there's an error, they should return an error. If there isn't, you should be able to inspect any other data and log it yourself if you choose to do so. A library doing its own logging is just annoying.</p></pre>karma_vacuum123: <pre><p>public/open-source libraries....sure....in-house libs...why not?</p>
<p>logs collect useful data. users of libraries do not know what it useful, in scope or volume...authors do. if both the user and author are committed to a logging platform (because they work together), its perfectly fine for libraries to log, particularly if the library already produces side-effects (logging is just one more)</p></pre>carsncode: <pre><p>In house libs, sure, but then we're back to "just make your own logging interface".</p></pre>PatrickTheHoss: <pre><p>I disagree. A logger with features like control of a logging namespace as well as control over logging levels within that namespace, ie "debug" or "error" would make it so you control what actually gets logged. </p>
<p>There are scenarios during development where it's useful to see the logical flow without having to bust open the source code every time you have a question.</p></pre>comradeswitch: <pre><p>I agreed with you until I worked on the largest, most complex project of my career and it turned out the easiest way to handle logging was to remove it from all of the libraries we wrote. It's one thing to just import a logging package and use a package-level logger while you're in development, but coordinating different handlers/formatters/levels in library loggers that are often used in multiple files/packages within a single project...it's bad. It's messy. You end up re-implementing so much in every library that is already included in every logging library already.</p>
<p>You do you, but I'd keep it simple for sanity's sake. Productivity, too. </p></pre>sseth: <pre><p>Sounds complicated dude.</p></pre>shovelpost: <pre><p>I don't know if a standard library interface would be a good idea or not but if it could stop this logging package madness and fragmentation we have in the ecosystem I'd sure love it if it existed.</p></pre>cs-guy: <pre><p>I don't think it would have that effect. I think different projects have legitimately different logging needs. Some need speed, some want convenience, some want levels, some want structure, and on and on. I don't think one logging package or interface will satisfy all needs, which means there will always be several alternatives that are popular for different reasons.</p>
<p>But that's OK, because logging is an application concern and as long as widely shared libraries don't couple themselves to a logging solution teams will be free to choose what they need for the application at hand.</p></pre>tophermck: <pre><p>This is exactly how I feel, it would be really nice to not enter a holy war about logging every-time my team start to talk about logging.</p></pre>The_Sly_Marbo: <pre><p>I'll probably be downvoted into oblivion here, but in my opinion the log package in the stdlib is more than adequate, so a logging interface is unnecessary.</p></pre>
