4 ms·
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
by cube2222 3y ago
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 3y agoI 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.
- philosopher1234 3y agoideally an slog handler is built for zerolog, so that you can use slog BE and keep the zerolog FE
- d1str0 3y agoTomorrow we will see a blog post titled “Why I always use 3rd part dependencies instead of stdlibs”
- chrsig 3y agoI 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 3y agoA little honesty is a good thing
- endorphine 3y agoYou can alias it when importing it then.
- resonantjacket5 3y agoI 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 3y agoI 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 3y agoIndeed it's in "golang.org/x/exp/slog"
- mdaniel 3y agohttps://pkg.go.dev/golang.org/x/exp/slog#hdr-Levels 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 3y agoThat 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.