5 ms·

It’s not without precedence, for example: https://pkg.go.dev/strings#NewReplacer https://pkg.go.dev/strings#NewReplacer I don’t mind it. You can use LogAttrs

by grose 3y ago

It’s not without precedence, for example: https://pkg.go.dev/strings#NewReplacer https://pkg.go.dev/strings#NewReplacer I don’t mind it. You can use LogAttrs if you want to be explicit. Although I do wonder if there’s anything tricky with the type system that is preventing something like this from being supported: https://go.dev/play/p/_YV7sYdnZ5V https://go.dev/play/p/_YV7sYdnZ5V

gdprrrr 3y ago
Is ordering of the keys guaranteed to be the same as in the literal?
- grose 3y ago
  That’s a good point. I think it would be random without some sorting shenanigans.
- kiitos 3y ago
  Order should be preserved up to the Handler. Some Handlers e.g. JSONHandler produce output with key order explicitly undefined.
ben0x539 3y ago
I think go loggers have tried to move away from passing log entries as maps for performance reasons.
- mlhpdx 3y ago
  That seems like a problem that should be solved. Logging structured data is a very basic expectation.
  - infogulch 3y ago
    This is structured logging. Stubbornly insisting that "structured logging" === "map" is dumb and ignores a large fraction of use cases where performance matters.
    - mlhpdx 3y ago
      Are there languages that solve the “performance“ problem with maps? In fact, isn’t Go one of them?
      - infogulch 3y ago
        In this use case using maps doesn't solve any problem, requires at least one allocation, and requires hashing each key. This is not even an interesting discussion.
        mlhpdx 3y ago
        I can see the case for flat logging, aka. key value logging, as an optimization for very, very performance critical code that needs to emit string logs. That however, isn’t mainstream in my experience. The far, far more common case is logging in code with complex data-driven behaviors where the data is structured (more than one level, not flat) and where forensic debugging via logs is a critical activity. If that’s not your world, you should only be interested in it if you’re interested in the community at large. If you’re not, that’s cool.
        59nadir 3y ago
        I think you seem to be arguing that the end result should be a "map"-like structure, whereas the other commenter is arguing about the interface to the logging library not being based on maps. These are not the same and taking maps in the interface is likely to incur allocations, yes. Having to specify your key-value pairs without maps is the only downside to not taking fully constructed maps in the interface.
        mlhpdx 3y ago
        Adding the application/component code to do ”good logging” is tedious. Friction in the interface decreases the probability it will be done well, and consistently. I think the interface matters, and while it’s a second order problem it does impact system quality in the long run. Just my opinions here. I don’t question the value of slog as it sits, just could have been better for the community at large is all.
  - yencabulator 3y ago
    Avoiding the map allocation & construction cost is way harder than avoiding the use of a map, like zap and slog.LogAttrs do.
masklinn 3y ago
You don’t need LogAttrs to pass in Attr entries, it should work fine with normal functions The reason it doesn’t use maps is that maps are significantly slower, TFA has an entire section on performances. However if you prefer that interface and don’t mind the performance hit, nothing precludes writing your own Logger (it’s just a façade over the Handler interface) and taking maps.

by grose 3y ago

gdprrrr 3y ago

Is ordering of the keys guaranteed to be the same as in the literal?

grose 3y ago
That’s a good point. I think it would be random without some sorting shenanigans.
kiitos 3y ago
Order should be preserved up to the Handler. Some Handlers e.g. JSONHandler produce output with key order explicitly undefined.

ben0x539 3y ago

I think go loggers have tried to move away from passing log entries as maps for performance reasons.

mlhpdx 3y ago
That seems like a problem that should be solved. Logging structured data is a very basic expectation.
- infogulch 3y ago
  This is structured logging. Stubbornly insisting that "structured logging" === "map" is dumb and ignores a large fraction of use cases where performance matters.
  - mlhpdx 3y ago
    Are there languages that solve the “performance“ problem with maps? In fact, isn’t Go one of them?
    - infogulch 3y ago
      In this use case using maps doesn't solve any problem, requires at least one allocation, and requires hashing each key. This is not even an interesting discussion.
      - mlhpdx 3y ago
        I can see the case for flat logging, aka. key value logging, as an optimization for very, very performance critical code that needs to emit string logs. That however, isn’t mainstream in my experience. The far, far more common case is logging in code with complex data-driven behaviors where the data is structured (more than one level, not flat) and where forensic debugging via logs is a critical activity. If that’s not your world, you should only be interested in it if you’re interested in the community at large. If you’re not, that’s cool.
        59nadir 3y ago
        I think you seem to be arguing that the end result should be a "map"-like structure, whereas the other commenter is arguing about the interface to the logging library not being based on maps. These are not the same and taking maps in the interface is likely to incur allocations, yes. Having to specify your key-value pairs without maps is the only downside to not taking fully constructed maps in the interface.
        mlhpdx 3y ago
        Adding the application/component code to do ”good logging” is tedious. Friction in the interface decreases the probability it will be done well, and consistently. I think the interface matters, and while it’s a second order problem it does impact system quality in the long run. Just my opinions here. I don’t question the value of slog as it sits, just could have been better for the community at large is all.
- yencabulator 3y ago
  Avoiding the map allocation & construction cost is way harder than avoiding the use of a map, like zap and slog.LogAttrs do.

masklinn 3y ago

You don’t need LogAttrs to pass in Attr entries, it should work fine with normal functions The reason it doesn’t use maps is that maps are significantly slower, TFA has an entire section on performances. However if you prefer that interface and don’t mind the performance hit, nothing precludes writing your own Logger (it’s just a façade over the Handler interface) and taking maps.