Hacker News Reader

Comment by cube2222 | Hacker News Reader

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.

View on HN

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.

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

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

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.

A little honesty is a good thing

You can alias it when importing it then.

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.

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.

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

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"

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.

Put the logger in the context

Isn't it considered bad practice?

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

> opentelemetry is basically a house of antipatterns

"Look on My Works Ye Mighty and Despair!"

https://github.com/open-telemetry/opentelemetry-collector/tr... -> https://github.com/open-telemetry/opentelemetry-collector-re... ... and then a reasonable person trying to load that mess into their head may ask 'err, what's the difference between go.opentelemetry.io/collector and github.com/open-telemetry/opentelemetry-collector-contrib?'

  $ curl -fsS go.opentelemetry.io/collector | grep go-import
  <meta name="go-import" content="go.opentelemetry.io/collector git https://github.com/open-telemetry/opentelemetry-collector">

Oh, I see. Thanks.

I don't enjoy the otel APIs, but they are implicitly scoped; contexts are a natural place to store them.

"The context stores request-scoped data" might be another Go-team dogma due for course correction RSN.

huh? there's no dogma involved here, it's just an observation of the properties of the type

a context is created with each request, and destroyed at the end of it

and values stored in a context are accessible only through un-typed, runtime-fallible methods -- not something you want to lean on, if you can avoid it

In practical terms there's pros & cons I guess, but in general doesn't loading a Context with session variables make code more concise and easier to understand ? DB connections, loggers, and the like. If you really want to pass around Context's in all your API signatures then at least try to make the most of it.

Are pitfalls ever actually encountered ?

if you pass a logger to a foo as a parameter to the foo constructor, then missing a logger is a compile-time error

if you pass a logger to a foo as a parameter in the request context, then missing a logger is a run-time error

Fer sher. But a passed-by-Context logger could be used (for example) to override a library package's default (stdlib?) logger.

But what is the SOP / Best Practice here ? Do many libraries have some sort of SetLogger(..) initialization call, so that loggers don't clutter the API ? Or are error returns info-(over-)loaded ?

it's pretty straightforward, everything that logs takes a logger as a dependency during construction

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

Reply on news.ycombinator.com