4 ms·

I'm intimately familiar with structured logging. The domain concepts defined by slog are unquestionably abnormal. From a structured logging package I would ex

by 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.
  - morelisp 3y ago
    > There is no reason to distinguish a Handler from a Logger. A Handler is an abstract type, a Logger is a concrete one. A Logger lets you have a large user surface (and without virtual calls); and Handler, a small implementer surface. (The handler is not much beyond what you proposed, plus an optimization to avoid materializing complete record+KV pairs if the level isn't met.) The concepts also map fairly directly to logrus and zerolog (which has an absolutely enormous surface to avoid boxing).
    - kiitos 3y ago
      If slog needs to avoid virtual calls or boxing or whatever else for reasons of performance, I guess I feel very strongly that it should do so in a way that doesn't impact users, and shouldn't let these concerns influence the API design.
      - morelisp 3y ago
        "Ignore performance when designing your API" is an obvious non-starter. I don't think you're serious. More specifically, users want the surface area Logger has. They do not want a single function with a complex object specification, just like they don't want a function per type.
        kiitos 3y ago
        There is obviously an enormous difference between "don't let performance influence your API (to become awkward or nonidiomatic)" and "ignore performance when designing your API".
        morelisp 3y ago
        But you've offered no actual criteria why the API is bad! Again, most logging users want something to handle nested record contexts for them and per-level methods, most logging implementers want a minimum number of entry points, and that's exactly what this API offers. (It's definitely not zerolog-style where it sacrifices ease of use for performance.)

by kiitos 3y ago

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.
- morelisp 3y ago
  > There is no reason to distinguish a Handler from a Logger. A Handler is an abstract type, a Logger is a concrete one. A Logger lets you have a large user surface (and without virtual calls); and Handler, a small implementer surface. (The handler is not much beyond what you proposed, plus an optimization to avoid materializing complete record+KV pairs if the level isn't met.) The concepts also map fairly directly to logrus and zerolog (which has an absolutely enormous surface to avoid boxing).
  - kiitos 3y ago
    If slog needs to avoid virtual calls or boxing or whatever else for reasons of performance, I guess I feel very strongly that it should do so in a way that doesn't impact users, and shouldn't let these concerns influence the API design.
    - morelisp 3y ago
      "Ignore performance when designing your API" is an obvious non-starter. I don't think you're serious. More specifically, users want the surface area Logger has. They do not want a single function with a complex object specification, just like they don't want a function per type.
      - kiitos 3y ago
        There is obviously an enormous difference between "don't let performance influence your API (to become awkward or nonidiomatic)" and "ignore performance when designing your API".
        morelisp 3y ago
        But you've offered no actual criteria why the API is bad! Again, most logging users want something to handle nested record contexts for them and per-level methods, most logging implementers want a minimum number of entry points, and that's exactly what this API offers. (It's definitely not zerolog-style where it sacrifices ease of use for performance.)