[grose]

It’s not without precedence, for example: 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

[ben0x539]

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

[mlhpdx]

That seems like a problem that should be solved. Logging structured data is a very basic expectation.

[infogulch]

This is structured logging. Stubbornly insisting that "structured logging" === "map" is dumb and ignores a large fraction of use cases where performance matters.

[mlhpdx]

Are there languages that solve the “performance“ problem with maps? In fact, isn’t Go one of them?

[infogulch]

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]

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.

[yencabulator]

Avoiding the map allocation & construction cost is way harder than avoiding the use of a map, like zap and slog.LogAttrs do.

[gdprrrr]

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

[kiitos]

Order should be preserved up to the Handler. Some Handlers e.g. JSONHandler produce output with key order explicitly undefined.

[grose]

That’s a good point. I think it would be random without some sorting shenanigans.

[masklinn]

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.