Typesafe API

[lpar]

I like the idea of a standard interface that can be used with any logging library. However, a big draw of zap, zerolog and other similar libraries is that they have type safety. As far as I can see, that's lost if logr is used.

So maybe consider giving logr a typesafe API, and having it use the typesafe APIs of the underlying loggers where there is one?

[thockin]

Can you tell me more what problem(s) you are looking to solve? Is it performance (where strong types might matter) or some other form of "safety"?

Is there a place where logr is unsafe?

[pohly]

I guess this is about preventing incorrect log calls like logger.Info("hello world", "missingvalue" /* , 42).

@lpar: both logr and slog are using linters to catch malformed key/value parameter. For slog it's built into "go vet", for logr we have https://github.com/timonwong/loggercheck and https://github.com/kubernetes-sigs/logtools/tree/main/logcheck.

Does this help?

[lpar]

Performance and avoiding malformed parameters, yes.

Linters aren't ideal, you have to get everyone to run them or else you don't catch errors until CI, which wastes time. There's a reason why we're using a statically-typed language rather than type linters (a la JavaScript), yes?

[thockin]

In my experience, the cost-benefit ratio just isn't there for most people. The performance win was pretty minimal when I last attempted this, and the uglification of callsites was significant.

log.V(2).Info("hello", "from", to, "to", to)

becomes something like:

log.V(2).InfoAttr("hello", logr.String("from", from), logr.String("to", to))

I appreciate all the effort that slog put into optimizing this path, but I think it's a waste for 99.9% of callsites.

On top of that, it's a lot of complexity on implementations.

We can't just overload Info/Error methods, because it's a breaking change to the API - old LogSink implementations would misinterpret. So we either add new methods (making uglification worse) or we disassemble the "tuples" in logr and pass the usual ...any arguments to backends (making perf slightly worse instead of better).

As always, I am open to being convinced, but I just don't see the ROI.

There's a reason why we're using a statically-typed language

If Go had proper tuples, none of this would be an issue. :(