On Fri, 8 Jul 2016 20:05:13 +0200 Peter Mogensen <a...@one.com> wrote:
[...] > > As soon as _advanced_ logging is required, you do several things: > > 1) Reconsider approach to logging. > > 2) Use a full-blown logging library. > > > > Note that (1) should not be underestimated. What is OK for a > > temporary log.Printf() call might not be OK for proper logging. > > Well ... I agree with the above. > Since that's often the way minor service daemons are prototyped and > developed. First you make stuff work - and the stdlib package is fine. > Then you make stuff work nicely and you might run into limitations. > And that's why I searched for a stdlib compatible full featured log > library ... found none, and wrote my own. > > Of course, one could (and some will) argue that it's not important to > be stdlib compatible, since you should do a total rework of all > logging at once when you do it. > That often a larger task, preventing it from being done at the best > moment though. People are reluctant to go through all the code, > replacing all logging with the verbose syntax of the more advanced > log libraries. > So in practice it's often nice to start by just replacing the stdlib > calls where you need it and still have everything work. I think I understand your concerns, and actually has nothing to say against them. The only possible (and very real) case is that easy to use full-blown logging tends to be abused in some circles, namely, in the Java world where every freaking JAR depends on log4j or something like this for no reason. But this topic has already been rehashed several times on this list (the consensus was, IIRC, that no library code has a luxury of using direct logging and has to expose some sort of callback-enabled code so that the user's main() could make use of its logging abilities when needed). > > So the standard log package is just the simplest thing possible. > > When you need something high-profile, simple ignore it and use the > > high-profile solution. And the standard package indeed allows to > > "start small". > > ... and it's my experience people often get stuck at "small" since > it's a non-trivial decision to replace all logging at once. > > > [*] If I would be designing the standard "log" package I'd made all > > Print*() function log to stdout and would have a matching set of > > Error*() functions which would log to stderr. > > Hmm... Not sure I see the use case for this. I don't get why "log" streams everything to stderr: Unix has two distinct standard output streams since forever precisely to be able to direct "normal" output to stdout and warnings/errors to stderr. This provides for two use-cases: 1) One can silence just the normal output or just the error output, if needed, which is sometimes useful for scripting. 2) Daemon supervision software such as daemon(1) or systemd usually have the nice property of being able to channel what your program being supervised outputs to its standard streams to the syslog (or other system-wide logging subsystem), and it uses the nature of the stream (stdout vs stderr) to mark the information as "nofices" or "errors", respectively. And I must say I like this: my software is not high-profile to I don't need specialized logging and instead love the ability to play nicely with the standard system logger. May be the envisioned use case for "log" was in the same venue as compiler warnings: if something was worth displaying, it supposedly was an error. ;-) Another possibility could be just using stdout for outputting _data_ (as opposed to messages) and using stderr for diagnostics. It would be interesting to hear from the implementors. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
