1. 2
  1.  

  2. 2

    When creating a project like that it’s important to inscribe it in the existing literature. Why was the library created? What are the alternatives?

    One thing I cannot live without anymore is having the ability to build a log context, for example attach the current request’s user ID is invaluable. It promotes consistent and easy to debug log messages which is really hard to achieve without that. https://github.com/sirupsen/logrus is a decent logging library that supports this.

    I guess for CLI application, it’s more important to have nice colors and that could be a nice niche for OP’s logging library.

    1. 2

      Couple suggestions:

      • Have an interface the logger implements that allow it to be used in other packages; generally we try to keep external dependencies minimal, and having the logger expose a basic interface lets us model that interface so we can accept other loggers in our packages. Example would be the logger type would have Printf and Errorf, then we can require our package loggers have those functions too, then we can swap in and out loggers easily.
      • Not a requirement, but this wouldn’t pass golint
      • Use of the init() function for packages is generally unnecessary and if you can work around it you should.

      If you want to see where we ended up with our logger: https://github.com/blend/go-sdk/tree/master/logger

      A couple key considerations there; log messages are “events” that are strongly typed, and get sent through an event bus so you can attach listeners to them; this is useful for collecting errors and writing request stats etc. by hooking into existing logging.