Add a logger / logging package

[omarkohl]

It makes debugging easier.

Some candidates (chosen via 10 minutes of googling):

• https://github.com/sirupsen/logrus
  • :x: Is in maintenance mode, which is not per-se bad but the README does mention that had it been designed today they would change things.
  • :heavy_check_mark: 23k stars, very popular
• https://github.com/rs/zerolog
  • It's inspired by zap but with even better performance
• https://github.com/apex/log
  • :x: Has centralization in mind, which is not my use case
• https://github.com/uber-go/zap/
  • Developed by a company, which can be a blessing and a curse
  • :heavy_check_mark: The design decision in the FAQ speak to me e.g. recommendations not to use a global logger and to create your own interface or the built-in support to panic in development but log an error in production
  • Emphasizes performance, which does not seem very important for me, on the other hand as they write, why not?
• https://github.com/inconshreveable/log15
  • No obvious pros or cons
• slog (https://pkg.go.dev/golang.org/x/exp/slog)
  • :heavy_check_mark: It was accepted for Go 1.21 (https://github.com/golang/go/issues/56345) so it seems like it will become part of the stdlib
  • Logrus, Zap and Zerolog are mentioned as prior work

[omarkohl]

• https://groups.google.com/g/golang-nuts/c/8boojTncXvs
• https://dave.cheney.net/2015/11/05/lets-talk-about-logging
• https://dave.cheney.net/2017/01/23/the-package-level-logger-anti-pattern
• https://peter.bourgon.org/go-best-practices-2016/

The above links recommend not to use a global logger but instead pass it into the functions or make it a struct field. Also it should be an interface, at least for the parts of the application that could be used as a library to avoid clients being forced to rely on the same logging library. You should only use levels DEBUG and INFO.