I see a lot of hate directed at the stdlib's log package, and of course, there are a medley of third party logging packages. What are people's problems with the standard log package? I've seen accusations that it doesn't have leveled logging, which seems like an exercise in laziness, because that's easy to write:
package log
import (
"io/ioutil"
"log"
"os"
)
var (
Trace = log.New(ioutil.Discard, "TRACE ", log.LstdFlags)
Debug = log.New(os.Stdout, "DEBUG ", log.LstdFlags)
// etc
)
With the above trivial package, you can now do log.Debug.Printf("foo!")
just like any of the third party loggers.
Some loggers are structured loggers, which again seems like not a big deal, you can pass a map[string]interface{} into log.Printf and it'll print out the map in a fairly easily parse-able way...
The only thing I can think of is that the time formatting is kinda ugly. I guess the other feature is being able to change levels of logs for individual packages, though honestly, in my ~10 years of working on projects that use such a feature, I think I've used it all of once or twice.
What am I missing?
Overall: What is the problem with third party loggers? Why not use a
package that gives you more power than the stdlib, that's what packages
are for, after all :)
A thing I forgot to mention btw, is: The log package exposes both a type
*log.Logger and a set of functions that use a default. But this default
is not exposed, so I as main can not even change how everyone is logging
(because, of course, everyone is just using the functions instead of
exposing their own logger).
On Nov 4, 2015 11:38 PM, "'Axel Wagner' via golang-nuts" <golan...@googlegroups.com> wrote:
>
> Hi,
>
> I am mostly indifferent towards the log package, but just as one note:
>
> Nate Finch <nate....@gmail.com> writes:
> > Trace = log.New(ioutil.Discard, "TRACE ", log.LstdFlags)
>
> This may *seem* like a good idea, but it still means, that the log
> package has to do all the formatting (just to not use it). If log.Logger
> had been an interface, you could replace this with a Logger that truly
> has NOPs.
Even then, if you put that no op logging in a tight loop, you'll see convT2E eating your lunch in profiles. For really efficient noop logging, you need an if statement (see the glog approach). (IMO this is one place where c-style macros can be quite useful -- they would allow you to completely omit code.)
> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
I don't believe this is true.
You can embed line numbers in errors, create a chain of errors with causes, and embed stack traces into errors ?
Have you seen Roger Peppe's errgo package, or juju/errors package which do this (albeit with slightly different philosophies) ?
type Logger interface { Log(keyvals ...interface{}) error}