Attrs

May 5, 2026

We’ve been talking about key/value pairs. The log/slog package has a name for these: Attr (short for “attribute”). And there’s more than one way to build an attribute:

Attrs and Values

An Attr is a key-value pair. The Logger output methods accept Attrs as well as alternating keys and values. The statement

slog.Info("hello", slog.Int("count", 3))

behaves the same as

slog.Info("hello", "count", 3)

There are convenience constructors for Attr such as Int, String, and Bool for common types, as well as the function Any for constructing Attrs of any type.

You might wonder why there are two ways to do this. I know I do!

I can guess, though: Allowing both convenience, and precision.

Passing raw key/value pairs is generally more convenient:

slog.Info("request served", "url", req.URL.String(), "method", req.Method, ...)

But it’s also error-prone. Particularly with long lists of attributes, it’s easy to miss either a key or a value, which can trigger all sorts of strange behavior!

There may also be times when you want to pass around attributes, and that’s often easier as discrete slog.Attr values than as a slice of key/value pairs.

And finally, there may be a marginal performance gain by using one of the type-specific attribute constructors, since it avoids a type assertion at runtime—not a concern most of us will ever need to worry about, of course.

So should you prever key/value pairs ("key", value), or the explicit attribute constructors (slog.Int("key", value)). Your call. I generally prefer the explicit constructors, because it’s more explicit, and less error prone—particularly if the log ever grows more key/value pairs over time. But: I would never hold up a code review because somebody else chose the other format instead!


Share this

Direct to your inbox, daily. I respect your privacy .

Unsure? Browse the archive .

Related Content


Lazy attribute evaluation for JSONHandler

As I was writing yesterday’s post, a portion of the GoDoc confused me. I’ve now spent over 3 hours with Claude trying to parse the prose grammatically, build test cases, and make general sense of it. I think I finally have… Here’s hoping! So, yesterday we saw how you can lazy-evaluate some values when using TextHandler. But the proposed solution (pass a fmt.Stringer rather than a literal string) has other, likely uninintended, consequences if you’re using JSONHandler:


Attribute evaluation

log.With isn’t the only trick available for improving performance of logging. Many values you may want to pass to a logger need to be calculated. And sometimes that calculation is expensive. And if a log is omitted, because it’s a debug log, and our logger is only configured for info-and-up level, that calculation should be skipped. Performance considerations … The arguments to a log call are always evaluated, even if the log event is discarded.


Performance considerations

You’ve likely wondered why the log/slog package has some odd-looking functions and concepts in some places. Why do you set a handler’s level to a Leveler value, rather than a simple Level? Why so many ways to create key/value pairs ("key", "value" vs "key", slog.AnyValue("value") vs "key", slog.StringValue("value") vs slog.Any("key", "value") vs slog.String("key", "value"))? It mostly comes down to one thing: Performance. Or, more accurately, trying to balance performance with an easy-to-use API.

Get daily content like this in your inbox!

Subscribe