undefined | Better HN

0 pointspeterldowns6mo ago0 comments

That's close, but not what I meant — that's specific to this package, and is the interface for processing log records produced by a slog.Logger. What I mean is that there should be a single interface for Logging that is implemented by slog.Logger, uber/zap.Logger, etc. that library authors can use without needing to reinvent the wheel every time.

For an example from one of my own libraries, see

https://github.com/peterldowns/pgmigrate/blob/d3ecf8e4e8af87...

0 comments

9rx6mo ago

> What I mean is that there should be a single interface for Logging that is implemented by slog.Logger, uber/zap.Logger, etc.

There is: https://pkg.go.dev/golang.org/x/exp/slog#Handler

If, say, zap was conformant, you'd slog.New(zap.NewHandler()) or whatever and away you go. It seems the only problem here is that the logging packages you want to use are not following the blessed, idiomatic path.

> For an example from one of my own libraries

There are a lot of problem with that approach at scale. That might not matter for your pet projects, but slog also has to serve those who are pushing computers to their limits. Your idea didn't escape anyone.

peterldownsOP6mo ago

I know it didn't escape anyone; I'm explaining the downside to the choices made by the stdlib authors, from my perspective. When performance is a concern, people pick uber/zap.Logger or zerolog. When performance isn't a huge concern, slog is overly complicated and annoying. I believe you understand my complaint.

9rx6mo ago

> I believe you understand my complaint.

I don't, really. If performance is of utmost concern, you're not going to accept the overhead of passing the logger through an interface anyway, so that's moot. A library concerned about performance as a top priority has to pick one and only one.

But if a library has decided that flexibility is more important than raw efficiency, then the interface is already defined.

    zaplogger.Info("Calling third-party library")
    thirdparty.Call(slog.New(zaplogger)) // Logs whatever the package logs to zaplogger
    zaplogger.Info("Called third-party library")

The only 'problem' I can see is if `zaplogger` hasn't implemented the interface. But there isn't much the Go team can do about implementations not playing nicely.

oefrha6mo ago

Your library should just take a *slog.Logger, and using *slog.Logger is an orthogonal choice to zap/zerolog/whatever. Those compete with slog.TextHandler or slog.JSONHandler, and sure, if you’re performance sensitive don’t pick them. In my newer projects I use zap under the hood with an application-facing *slog.Logger through go.uber.org/zap/exp/zapslog just fine (actually further locked down with my own interface so that coworkers can’t go crazy, but that’s beside the point). Your bespoke interface, or that standard interface you want isn’t going to be any more performant than going through slog.Handler interface anyway.

j / k navigate · click thread line to collapse

0 comments

9rx6mo ago

> What I mean is that there should be a single interface for Logging that is implemented by slog.Logger, uber/zap.Logger, etc.

There is: https://pkg.go.dev/golang.org/x/exp/slog#Handler

> For an example from one of my own libraries

peterldownsOP6mo ago

9rx6mo ago

> I believe you understand my complaint.

But if a library has decided that flexibility is more important than raw efficiency, then the interface is already defined.

    zaplogger.Info("Calling third-party library")
    thirdparty.Call(slog.New(zaplogger)) // Logs whatever the package logs to zaplogger
    zaplogger.Info("Called third-party library")

The only 'problem' I can see is if `zaplogger` hasn't implemented the interface. But there isn't much the Go team can do about implementations not playing nicely.

oefrha6mo ago

j / k navigate · click thread line to collapse