[politician]

I wish there was a better approach for the problem of avoiding function calls when the log level at runtime is higher than the call site.

So,

    slog.Info("failed to frob", "thing", GetThing(1)) 

Still calls GetThing(1) when the log level is greater than Info. The only solution right now for this is to test the log level before making the logging call. It would be amazing if language designers could make the arguments late bound instead or used aspect-oriented programming approaches to protect each logging call site.

[sa46]

There is. See slog.LogValuer

https://pkg.go.dev/golang.org/x/exp/slog#LogValuer

[jeffbee]

There are other languages of course where the logging avoids this, even in libraries written by the same company that writes Go. In C++, the Abseil logging library (f.k.a. glog) will not evaluate a condition for a disabled log level.

  LOG(INFO) << WowExpensiveFunction();

This is safe when the log level is set to WARN or higher. For the same reasons, LOG_EVERY_N and LOG_FIRST_N in the same library are pretty cheap.

[yencabulator]

https://pkg.go.dev/log/slog#hdr-Performance_considerations