3 ms·

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

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.
    - deleted 3y ago
      [deleted]
    - cube2222 3y ago
      > An Attr is a key-value pair. So s/KeyValuePair/Attr/g? Re varargs vs record, varargs are usually used in Go because they're very ergonomic to write inline, so they work very nice with loggers. Group sounds like a fairly arbitrary concept, I agree, but still very reasonable for something that's supposed to standardize things. It would totally make sense for e.g. different libraries to each inject their own group with key-values into the context. I'm not sure what's the problem with Handlers? This is supposed to be a standard library package that is setting... well, standards that other libraries will adhere to. Handlers let you plug your own output formats. The package is not supposed to be "as bare bones as possible". Just "good default others will be able to integrate and compose with". I've used my fair share of structured loggers too, and this really is par for the course and a completely reasonable set of things to include in a structured logging package. --- It's worth noting that the previously-mentioned Zap, which is probably the most popular structured logging library in go right now, contains all the same concepts, just differently named: Attr -> Field Group -> Namespace Record -> Entry Handler -> Encoder/Writer
      - kiitos 3y ago
        There is no reason to distinguish a Handler from a Logger. A Handler is just a Logger which has a side effect, nothing more. There is no reason to distinguish an Attr or Group or Record from a (set of) KeyValuePairs. They're all the same thing. And I don't agree that Zap is the most popular structured logging library. It's one of many, none are the clear winner. But, whatever.

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.
  - deleted 3y ago
    [deleted]
  - cube2222 3y ago
    > An Attr is a key-value pair. So s/KeyValuePair/Attr/g? Re varargs vs record, varargs are usually used in Go because they're very ergonomic to write inline, so they work very nice with loggers. Group sounds like a fairly arbitrary concept, I agree, but still very reasonable for something that's supposed to standardize things. It would totally make sense for e.g. different libraries to each inject their own group with key-values into the context. I'm not sure what's the problem with Handlers? This is supposed to be a standard library package that is setting... well, standards that other libraries will adhere to. Handlers let you plug your own output formats. The package is not supposed to be "as bare bones as possible". Just "good default others will be able to integrate and compose with". I've used my fair share of structured loggers too, and this really is par for the course and a completely reasonable set of things to include in a structured logging package. --- It's worth noting that the previously-mentioned Zap, which is probably the most popular structured logging library in go right now, contains all the same concepts, just differently named: Attr -> Field Group -> Namespace Record -> Entry Handler -> Encoder/Writer
    - kiitos 3y ago
      There is no reason to distinguish a Handler from a Logger. A Handler is just a Logger which has a side effect, nothing more. There is no reason to distinguish an Attr or Group or Record from a (set of) KeyValuePairs. They're all the same thing. And I don't agree that Zap is the most popular structured logging library. It's one of many, none are the clear winner. But, whatever.