On Fri, 8 Jul 2016 19:14:27 +0200
Peter Mogensen <a...@one.com> wrote:
> > I disagree - if you have no need for structured logging, why reach
> > for a library? Stdlib seems to work just fine until you run into a
> > large amount of log output that is mission critical or you want to
> > start shipping these logs off to a third party for parsing (like
> > data-dog).
>
> 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.
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".
[*] 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.
--
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.
