Logging in Go with Slog: A Practitioner's Guide
1–10 of 59 posts
Re: Logging in Go with Slog: A Practitioner's Guide
#2I'm surprised this isn't a standard base pattern in languages, to be honest. Apache's commons-logging library was a standard part of enterprise java placements for many years, and only started to go away when Log4J came along.
Re: Logging in Go with Slog: A Practitioner's Guide
#3I'm a big fan of slog, and this is a great overview.
The fact it is so flexible and composable, while still maintaining a simple API is just great design. I wasn't aware of the performance overhead compared to something like zerolog, but this shouldn't be a concern for most applications.
Re: Logging in Go with Slog: A Practitioner's Guide
#4My biggest gripe with slog is that there is no clear guidance on supported types of attributes.
One could argue that supported types are the ones provided by Attr "construct" functions (like slog.String, slog.Duration, etc), but it is not enough. For example, there is no function for int32 – does it mean it is not supported? Then there is slog.Any and some support in some handlers for error and fmt.Stringer interfaces. The end result is a bit of a mess.
Re: Logging in Go with Slog: A Practitioner's Guide
#5I'm surprised this isn't a standard base pattern in languages, to be honest. Apache's commons-logging library was a standard part of enterprise java placements for many years, and only started to go away when Log4J came along.
Log4j is one of the possible backends for commons logging (and was basically the reason for it - choosing between log4j and the built-in java logging). I think you mean SLF4J?
Re: Logging in Go with Slog: A Practitioner's Guide
#6My biggest gripe with slog is that there is no clear guidance on supported types of attributes. One could argue that supported types are the ones provided by Attr "construct" functions (like slog.String, slog.Duration, etc), but it is not enough. For example, there is no function for int32 – does it mean it is not supported? Then there is slog.Any and some support in some handlers for error and fmt.Stringer interface…
All values are supported.
Re: Logging in Go with Slog: A Practitioner's Guide
#7I have a gripe with slog - it uses magic for config
What I mean is, if you configure slog in (say) your main package, then, by magic, that config is used by any call to slog within your application.
There's no "Oh you are using this instance of slog that has been configured to have this behaviour" - it's "Oh slog got configured so that's the config you have been given"
I've never tried to see if I can split configs up, and I don't have a usecase, it just strikes me as magic is all
Re: Logging in Go with Slog: A Practitioner's Guide
#8I have a gripe with slog - it uses magic for config What I mean is, if you configure slog in (say) your main package, then, by magic, that config is used by any call to slog within your application. There's no "Oh you are using this instance of slog that has been configured to have this behaviour" - it's "Oh slog got configured so that's the config you have been given" I've never tried to see if I can split configs u…
There's a default logger that's used when you call package-level functions (as opposed to methods on an instance of slog.Logger). The default logger is probably what you configured in your main package.
In my opinion this is perfectly idiomatic Go. Sometimes the package itself hosts one global instance. If you think that's "magic" then you must think all of Go is magic. It helps to think of a package in Go as equivalent to a single Java class. Splitting up a Go package's code into multiple files is purely cosmetic.
Re: Logging in Go with Slog: A Practitioner's Guide
#9I'm surprised this isn't a standard base pattern in languages, to be honest. Apache's commons-logging library was a standard part of enterprise java placements for many years, and only started to go away when Log4J came along.
Log4j is one of the possible backends for commons logging (and was basically the reason for it - choosing between log4j and the built-in java logging). I think you mean SLF4J?
I may be remembering it wrong, but I think log4j only became a commons logging backend several years after it became mainstream; before that I remember the two being entirely different and no interchangeable. It's a long time ago!
Re: Logging in Go with Slog: A Practitioner's Guide
#10I have a gripe with slog - it uses magic for config What I mean is, if you configure slog in (say) your main package, then, by magic, that config is used by any call to slog within your application. There's no "Oh you are using this instance of slog that has been configured to have this behaviour" - it's "Oh slog got configured so that's the config you have been given" I've never tried to see if I can split configs u…
There's a default logger that's used when you call package-level functions (as opposed to methods on an instance of slog.Logger). The default logger is probably what you configured in your main package. In my opinion this is perfectly idiomatic Go. Sometimes the package itself hosts one global instance. If you think that's "magic" then you must think all of Go is magic. It helps to think of a package in Go as equival…
If you need log output in tests, you should use an instance of a logger.
More teams should be validating their logging and should be leveraging structured logging and getting valuable logging insights/events.