[cube2222]

I'm a bit surprised that the slog package was added to the stdlib, but it does seem to use the API that I think is the most ergonomic across libraries I saw in Go (specifically, varargs for key values, and the ability to create subloggers using .With), so I guess it's nice most of the community will standardize around it.

If all goes well, you won't have different libraries using different loggers anymore, in some not too distant future, which should improve easy composability.

[fourseventy]

I literally just updated all of my golang logging to use zerolog so i could get severity levels in my logs. Bad timing on my part! I guess ill re-do it all with slog, i prefer stdlib packages to third party packages.

[d1str0]

Tomorrow we will see a blog post titled “Why I always use 3rd part dependencies instead of stdlibs”

[philosopher1234]

ideally an slog handler is built for zerolog, so that you can use slog BE and keep the zerolog FE

[chrsig]

I have mixed feelings about it. if nothing else, the name..."slog" isn't exactly the word i want repeating to myself as I'm working.

[tomjakubowski]

A little honesty is a good thing

[endorphine]

You can alias it when importing it then.

[resonantjacket5]

I think it's pretty exciting. Don't have to keep using regex or weird parsing to get the key values from logs that one wants.

Also a bit surprised how fast it was added to the stdlib, but perhaps there was a lot more consensus on the api compared to other golang proposals.

[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?