[vl]

I wonder if it's possible to use slog in 1.20 already, is there a back-port?

I'm changing logging on the service right now and it just makes sense to use it now, but entire service can't move to pre-release version of go.

[onionisafruit]

Indeed it's in "golang.org/x/exp/slog"

[mdaniel]

https://pkg.go.dev/golang.org/x/exp/slog#hdr-Levels seems to fall into the same trap that drives me _starkraving_ about the 18,000 different(!) golang logging packages: there doesn't seem to be a sane way of influencing the log level at runtime if the author doesn't have the foresight/compassion to add a command-line flag or env-var to influence it. A similar complaint about the "haha I log json except this other dep that I import who logs using uber/zap so pffft if you try to parse stdout as json"

[onionisafruit]

That bugs me too. I consider it a red flag for a library to log to anything except a `log.Logger` passed in from the caller. Now I'll expand that to include a `slog.Logger` as well. If the library is logging directly to stderr or stdout, that is a sign that it probably has other design issues as well.

[lokar]

Put the logger in the context

[vl]

Isn't it considered bad practice?

[preseinger]

yes, in general

the context stores request-scoped data, whether or not the logger is a request-scoped value is a grey area

and to reply to sibling comment, opentelemetry is basically a house of antipatterns, definitely do not look to it for guidance

[tptacek]

It's already idiomatic for OpenTelemetry, and otel has use cases that overlap slog.