On 2016-07-08 19:56, Konstantin Khomoutov wrote:
On Fri, 8 Jul 2016 19:14:27 +0200
Peter Mogensen <a...@one.com> wrote:
The standard log library doesn't support logging simple
"<level>message".
At least not in an efficient way.
But that's precisely what Zachary is advocating (and I'm with him on
this): there can't be one-size-fits-all solution for logging so there's
no sense to codify one of them. For instance, for the needs of most of
my applications the standard does even more I'd expect: I tend to stick
log.SetFlags(0)
at the start of my main() to inhibit timestamps in log messages.
And it provides for simple logging and printf-style debugging just
almost right amount of functionality (not ideal [*] but OK).
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.
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.
/Peter
--
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.
