5 ms·

I am really excited to start using the new structured logger.

iamcalledrob 3y ago
Yes! Logging always felt like something that (1) almost every project needs, and (2) there are too many 3rd party packages, with no "de facto" choice. This is particularly painful when working with 3rd party library code. There's a high chance that the consumer of library code uses a different logging package to the library author. Having structured logging in the stdlib is fantastic, because now there is a "go way" to this that libraries can use.
- eberkund 3y ago
  Does this mean that all the third party logging packages will likely die out in the future? Or will they likely implement adapters to be compatible with the std interface?
  - cratermoon 3y ago
    From the original proposal <https://go.googlesource.com/proposal/+/master/design/56345-structured-logging.md https://go.googlesource.com/proposal/+/master/design/56345-s...> 1 "We expect existing logging packages to coexist with this one for the foreseeable future." 2 "We expect that this proposal’s handlers will be implemented for all popular logging formats and network protocols, and that every common logging framework will provide a shim from their own backend to a handler"
kiitos 3y ago
Even after seeing the API, which is enormous and wildly non-intuitive?
- cube2222 3y ago
  Could you expand what you mean? When skimming it I mostly saw the common API structure that I usually see in libraries / write myself when I need a logger, so I generally welcome the standardization.
  - kiitos 3y ago
    slog defines the concepts of - Logger -- created by New, accepting a Handler, providing a fixed set of level-based logging methods, asserting concepts of Attrs and Groups, not parameterizable by consumers - Handler -- with two default implementations, asserting concepts of Attrs Groups and Records, parameterizable by consumers as long as they follow the semantics defined by the interface - Attr -- arbitrary concept that maps to a k/v pair in a log record - Group -- arbitrary concept that namespaces a set of k/v pairs in a log record - Record -- arbitrary concept that requires a timestamp (expensive to compute), a level (one of a specifically defined enum which cannot be changed), and a PC stack pointer (obvious issues there) I've never seen a logging package which meets these requirements.
    - metaltyphoon 3y ago
      If you meant on other ecosystems Microsoft.Extensions.Logging
    - cube2222 3y ago
      What else would you expect from a structured logging package? To me it absolutely makes sense as the default and standard for 99% of applications, and the API isn't much unlike something like Zap[0] (a popular Go structured logger). The attributes aren't an "arbitrary" concept, they're a completely normal concept for structured loggers. Groups are maybe less standard, but reasonable nevertheless. The timestamp is not required - the documentation specifies it can be left as the zero value and shall be ignored in that case. I'm not sure if you're aware that this is specifically a structured logging package. There already is a "simple" logging package[1] in the stdlib, has been there for ages, and isn't particularly fast either to my knowledge. If you want really fast you take a library (which would also make sure to optimize allocations heavily). [0]: https://pkg.go.dev/go.uber.org/zap https://pkg.go.dev/go.uber.org/zap [1]: https://pkg.go.dev/log https://pkg.go.dev/log
      - kiitos 3y ago
        I'm intimately familiar with structured logging. The domain concepts defined by slog are unquestionably abnormal. From a structured logging package I would expect a far simpler Logger API with a Log method something like Log(pairs ...KeyValuePair) error or maybe Log(r Record) error and no concept of Attrs or Groups or (explicit) Handlers.
- badrequest 3y ago
  I've seen the API, and it's not either of those things if you've already used a structured logger?
  - kiitos 3y ago
    I've never seen a structured logging library with concepts like Attrs, Groups, or Records like those defined by slog.
    - yencabulator 3y ago
      Attr is the same concept as https://pkg.go.dev/go.uber.org/zap#Field https://pkg.go.dev/go.uber.org/zap#Field , and Zap pioneered this whole field. Group is pretty much https://pkg.go.dev/go.uber.org/zap#Namespace https://pkg.go.dev/go.uber.org/zap#Namespace Record is the interface to log sinks, not something the typical programmer worries about.
      - kiitos 3y ago
        Haha, zap did not pioneer anything, what are you talking about.
        yencabulator 3y ago
        "Haha", great attitude dissing other people's work. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html What Go structured logging libraries predate Zap's 2016 creation? Only one I can remember is Logrus, which was using type Fields map[string]interface{}, the bad qualities of which are kinda the whole reason for Zap's creation, and slog follows the Zap-style API[1]. [1]: Though ignoring many of the optimizations..

Yes! Logging always felt like something that (1) almost every project needs, and (2) there are too many 3rd party packages, with no "de facto" choice. This is particularly painful when working with 3rd party library code. There's a high chance that the consumer of library code uses a different logging package to the library author. Having structured logging in the stdlib is fantastic, because now there is a "go way" to this that libraries can use.

eberkund 3y ago
Does this mean that all the third party logging packages will likely die out in the future? Or will they likely implement adapters to be compatible with the std interface?
- cratermoon 3y ago
  From the original proposal <https://go.googlesource.com/proposal/+/master/design/56345-structured-logging.md https://go.googlesource.com/proposal/+/master/design/56345-s...> 1 "We expect existing logging packages to coexist with this one for the foreseeable future." 2 "We expect that this proposal’s handlers will be implemented for all popular logging formats and network protocols, and that every common logging framework will provide a shim from their own backend to a handler"

kiitos 3y ago

Even after seeing the API, which is enormous and wildly non-intuitive?

cube2222 3y ago
Could you expand what you mean? When skimming it I mostly saw the common API structure that I usually see in libraries / write myself when I need a logger, so I generally welcome the standardization.
- kiitos 3y ago
  slog defines the concepts of - Logger -- created by New, accepting a Handler, providing a fixed set of level-based logging methods, asserting concepts of Attrs and Groups, not parameterizable by consumers - Handler -- with two default implementations, asserting concepts of Attrs Groups and Records, parameterizable by consumers as long as they follow the semantics defined by the interface - Attr -- arbitrary concept that maps to a k/v pair in a log record - Group -- arbitrary concept that namespaces a set of k/v pairs in a log record - Record -- arbitrary concept that requires a timestamp (expensive to compute), a level (one of a specifically defined enum which cannot be changed), and a PC stack pointer (obvious issues there) I've never seen a logging package which meets these requirements.
  - metaltyphoon 3y ago
    If you meant on other ecosystems Microsoft.Extensions.Logging
  - cube2222 3y ago
    What else would you expect from a structured logging package? To me it absolutely makes sense as the default and standard for 99% of applications, and the API isn't much unlike something like Zap[0] (a popular Go structured logger). The attributes aren't an "arbitrary" concept, they're a completely normal concept for structured loggers. Groups are maybe less standard, but reasonable nevertheless. The timestamp is not required - the documentation specifies it can be left as the zero value and shall be ignored in that case. I'm not sure if you're aware that this is specifically a structured logging package. There already is a "simple" logging package[1] in the stdlib, has been there for ages, and isn't particularly fast either to my knowledge. If you want really fast you take a library (which would also make sure to optimize allocations heavily). [0]: https://pkg.go.dev/go.uber.org/zap https://pkg.go.dev/go.uber.org/zap [1]: https://pkg.go.dev/log https://pkg.go.dev/log
    - kiitos 3y ago
      I'm intimately familiar with structured logging. The domain concepts defined by slog are unquestionably abnormal. From a structured logging package I would expect a far simpler Logger API with a Log method something like Log(pairs ...KeyValuePair) error or maybe Log(r Record) error and no concept of Attrs or Groups or (explicit) Handlers.
badrequest 3y ago
I've seen the API, and it's not either of those things if you've already used a structured logger?
- kiitos 3y ago
  I've never seen a structured logging library with concepts like Attrs, Groups, or Records like those defined by slog.
  - yencabulator 3y ago
    Attr is the same concept as https://pkg.go.dev/go.uber.org/zap#Field https://pkg.go.dev/go.uber.org/zap#Field , and Zap pioneered this whole field. Group is pretty much https://pkg.go.dev/go.uber.org/zap#Namespace https://pkg.go.dev/go.uber.org/zap#Namespace Record is the interface to log sinks, not something the typical programmer worries about.
    - kiitos 3y ago
      Haha, zap did not pioneer anything, what are you talking about.
      - yencabulator 3y ago
        "Haha", great attitude dissing other people's work. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html What Go structured logging libraries predate Zap's 2016 creation? Only one I can remember is Logrus, which was using type Fields map[string]interface{}, the bad qualities of which are kinda the whole reason for Zap's creation, and slog follows the Zap-style API[1]. [1]: Though ignoring many of the optimizations..