It's fine for application logging but I have two gripes with slog:
1) If you're writing a library that can be used by many different applications and want to emit logs, you'll still need to write a generic log interface with adapters for slog, zap, charmlog, etc. That the golang team refuses to bless a single interface for everyone to settle on both makes sense given their ideological standpoint on shipping interfaces and also causes endless mild annoyance and code duplication.
2) I believe it's still impossible to see the correct callsite in test logs when using slog as the logger. For more information, see https://github.com/neilotoole/slogt?tab=readme-ov-file#defic.... It's possible I'm out of date here — please correct me if this is wrong, it's actually a much larger annoyance for me and one of the reasons I still use uber/zap or charmbracelet/log.
Overall, especially given that it performs worse than uber/zap and everyone has basically standardized on that and it provides essentially the same interface, I recommend using uber/zap instead.
EDIT: just to expand further, take a look at the recommended method of wrapping helper methods that call logs. Compare to the `t.Helper()` approach. And some previous discussion. Frustrating!
I used slog.Logger for an OSS project and I will not do it again. The interface is terrible, and far more verbose and less expressive than something like Zap or zerolog. e.g. there's not really anything as good as zerolog's log.Dict() for dealing with complex structures.
1) The idea is that your library should accept the slog logger and use it. The caller would create a logger with a handler that defines how log messages are handled. But there are problems with supported types; see my other comments.
1) Right, but this is complicated and annoying. Imagine a world where you could just pass your existing logger in, because my library references an interface like `stdlib/logging.GenericLoggerInterface` and slog, zap, zerolog, etc. all implement that! Would be nice!
2) TIL about `T.Output`, thank you, that's great to know about. Still annoying and would be nice if the slog package showed an example of logging from tests with correct callsites. Golang gets so many things right about testing, so the fact that logging in tests is difficult really stands out and bothers me.
But that is exactly what slog provides? The a unified interface that can be implemented by other logger libraries. Yes the Logger itself is not the interface, but the Handler it is backed by is.
If zap, charmlog, etc. don't provide conformance to the interface, that's not really on the Go team. It wouldn't be that hard to write your own adapter around your unidiomatic logger of choice if you're really stuck, though. This isn't an actual problem unless you think someone else owes you free labor for some reason.
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.
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.
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.
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.
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.
The thing that gets me about slog is that the output key for the slog JSON handler is msg, but that's not compatible with Googles own GCP Stackdriver logging. Since that key is a constant I now need to use an attribute replacer to change it from msg to message (or whatever it is stackdriver wants). Good work Google.
My 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.
So the code that uses slog but does not know what handler will be used can't rely on it lazily calling the `String() string` method: half of the standard handlers do that, half don't.
And I know that I can create a wrapper for unsupported types. My problem is exactly that – I don't know what types are supported. Is error supported, for example? Should I create a wrapper for it? And, as a handler author, should I support it directly or not?
Not sure what your definition of "supported" is, but I'm afraid you're going to have to bite the bullet and ... gasp ... read the documentation https://pkg.go.dev/log/slog
Not sure I understand your sarcasm. I read the documentation, source code, handler writing guide, and issues in the Go repository multiple times over two years, and I use slog extensively. Go is my primary language since r60. I think I know how to read Go docs.
Now, please point me to the place in the documentation that says if I can or can't use a value implementing the error interface as an attribute value, and will the handler or something else would call the `Error() string` method.
My definition of "supported" is simple – I could pass a supported value to the logger and get a reasonable representation from any handler. In my example, the JSON handler does not provide it for the fmt.Stringer.
> Values are formatted as with an encoding/json.Encoder with SetEscapeHTML(false), with two exceptions.
> First, an Attr whose Value is of type error is formatted as a string, by calling its Error method. Only errors in Attrs receive this special treatment, not errors embedded in structs, slices, maps or other data structures that are processed by the encoding/json package.
So the json handler more or less works as if you called json.Marshal, which sounds pretty reasonable.
I think you missed the “any handler” part. Currently, the types that my library package could use depend on the handler used by the caller. This limits types to an unspecified subset, making things quite impractical.
The output of data is handled by the handler. Such behaviour is clearly outlined in the documentation by the JSONHandler. I wouldn't expect a JSONHandler to use Stringer. I'd expect it to use the existing JSON interfaces, which it does.
I'd expect the Text handler to use TextMarshaller. Which it does. Or Stringer, which it does implicitly via fmt.Sprintf.
My problem with that is that it makes it impossible to use slog logger safely without knowing what handler is being used. Which kind of defeats the purpose of defining the common structured logging interface.
As a producer of the response, if I didn't care about being understood, I would use a made-up language. As a consumer, you may care about understanding my response, but you cannot do anything about it.
Hence the design. The producer coming up with a made up language that makes sense to the producer, but probably doesn't make sense to the consumer — especially when you have many different consumers with very different needs — is far more problematic than the producer providing an abstract representation and allowing the consumer to dig into the specific details it wants.
As with everything in life, there are tradeoffs to that approach, of course, and it might be hard to grasp if you come from languages which different idioms that prioritize producer over consumer, but if you look closely everything about Go is designed to prioritize the needs of the consumer over the needs of the producer. That does seem to confuse a lot of people, interestingly. I expect because it isn't idiomatic to prioritize the consumer in a lot of other languages and people get caught up in trying to write code in those other languages using Go syntax instead of actually learning Go.
A good, if a bit strange, example. A CPI logger wouldn't need to log the same thing as an access logger, but the producer need not care about who is consuming the logs. Consumers might even want to see both and, given the design, can have both.
Certainly logs lose their value if they are wrong. And either approach is ripe for getting things wrong. But the idea is that the consumer is more in tune with getting what the consumer needs right. The producer's assumptions are most likely to be wrong, fundamentally, not having the full picture of what is needed. What is the counter suggestion?
We've banned this account for continually posting unsubtantive comments and ignoring our previous request to observe the guidelines.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
> The key decision is thus between two patterns: using a global logger or using dependency injection. The former is extremely convenient but adds a hidden dependency that’s hard to test, while the latter is more verbose but makes dependencies explicit, resulting in highly testable and flexible code.
Curious how different people handle this. I personally pretty much always pass a logger into function, classes, structs (what have you) so it has the context I need it to. It's a tad more verbose I guess, but it's such a minor lift I've always found it worth it.
In any API service, it's better to handle via dependency injection IMO.
Instantiate all of your metadata once, and then send that logger down, so that anybody who uses that logger is guaranteed to have the right metadata... the time to add logging is not when you are debugging.
I'd say necessarily verbose. Without injection, it is not immediately apparent that something is dependent on something else (in this case a logger) with side effects, which ultimately harms understandability.
I expect by "more verbose" the author really meant "in need of more typing". I am not sure optimizing for less typing ever a good tradeoff. And if you can find good reason to optimize for less typing, you're not going to be choosing a structured language in the first place, so...
Totally agree. I'll suffer with an additional 20 characters of typing. I hadn't even considered the other ways the article goes into, I'd always used a child logger and passed it down, so I'm a bit reassured that I haven't been a _complete_ fool for all these years.
I really like structured logs and am pleased the Go team saw the benefits of bringing it into the standard library.
However, I feel like errors should be able to hold slog attributes. It makes for some very useful and easy error logging, especially when the logging takes place far up the execution chain from where the error happened.
This is easily possible with a custom error type and some log functions. I have published on GitHub my small and crude implementation that I use in a few hobby projects, MIT licensed, if anyone is interested. https://github.com/sveinnthorarins/sterlo
I'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!
To guarantee correctness, you must use the strongly-typed slog.Attr helpers. They make it impossible to create an unbalanced pair by catching errors at compile time
I take their point, but given the typical value of most logging lines, this does not seem worth the tax you pay in readability. This is a gripe I have with oTel too --- it really cruds your code up --- but with oTel you're getting long-term value that logging (which is still my go-to o11y) doesn't.
I'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.
I 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
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.
I’m not sure I understand what you mean by “magic for config”. You create and configure a logger using slog.New(…). You can use the default logger instead, slog.Default(), which is just a global and has a default config. You can also set the default logger using slog.SetDefault(…).
It's fine for application logging but I have two gripes with slog:
1) If you're writing a library that can be used by many different applications and want to emit logs, you'll still need to write a generic log interface with adapters for slog, zap, charmlog, etc. That the golang team refuses to bless a single interface for everyone to settle on both makes sense given their ideological standpoint on shipping interfaces and also causes endless mild annoyance and code duplication.
2) I believe it's still impossible to see the correct callsite in test logs when using slog as the logger. For more information, see https://github.com/neilotoole/slogt?tab=readme-ov-file#defic.... It's possible I'm out of date here — please correct me if this is wrong, it's actually a much larger annoyance for me and one of the reasons I still use uber/zap or charmbracelet/log.
Overall, especially given that it performs worse than uber/zap and everyone has basically standardized on that and it provides essentially the same interface, I recommend using uber/zap instead.
EDIT: just to expand further, take a look at the recommended method of wrapping helper methods that call logs. Compare to the `t.Helper()` approach. And some previous discussion. Frustrating!
- https://pkg.go.dev/log/slog#example-package-Wrapping
- https://github.com/golang/go/issues/59145#issuecomment-14770...
The blessed interface for libraries is to accept a slog.Logger.
The blessed interface for logging backends is slog.Handler.
Applications can then wire that up with a handler they like, for example
zap: https://pkg.go.dev/go.uber.org/zap/exp/zapslog#Handler
charm https://github.com/charmbracelet/log?tab=readme-ov-file#slog...
I used slog.Logger for an OSS project and I will not do it again. The interface is terrible, and far more verbose and less expressive than something like Zap or zerolog. e.g. there's not really anything as good as zerolog's log.Dict() for dealing with complex structures.
1) The idea is that your library should accept the slog logger and use it. The caller would create a logger with a handler that defines how log messages are handled. But there are problems with supported types; see my other comments.
2) It is improved in 1.25. See https://github.com/golang/go/issues/59928 and https://pkg.go.dev/testing#T.Output. Now it is possible to update slogt to provide correct callsite – the stack depth should be the same.
1) Right, but this is complicated and annoying. Imagine a world where you could just pass your existing logger in, because my library references an interface like `stdlib/logging.GenericLoggerInterface` and slog, zap, zerolog, etc. all implement that! Would be nice!
2) TIL about `T.Output`, thank you, that's great to know about. Still annoying and would be nice if the slog package showed an example of logging from tests with correct callsites. Golang gets so many things right about testing, so the fact that logging in tests is difficult really stands out and bothers me.
But that is exactly what slog provides? The a unified interface that can be implemented by other logger libraries. Yes the Logger itself is not the interface, but the Handler it is backed by is.
We switched to zerolog a while back and didn't look back.
> That the golang team refuses to bless a single interface for everyone to settle on
Uh... https://pkg.go.dev/golang.org/x/exp/slog#Handler
If zap, charmlog, etc. don't provide conformance to the interface, that's not really on the Go team. It wouldn't be that hard to write your own adapter around your unidiomatic logger of choice if you're really stuck, though. This isn't an actual problem unless you think someone else owes you free labor for some reason.
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...
> 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.
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.
> 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.
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.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.
The thing that gets me about slog is that the output key for the slog JSON handler is msg, but that's not compatible with Googles own GCP Stackdriver logging. Since that key is a constant I now need to use an attribute replacer to change it from msg to message (or whatever it is stackdriver wants). Good work Google.
We had the same annoyance, and wrote https://pkg.go.dev/github.com/chainguard-dev/clog/gcp to bridge the gap.
It's a slog handler that formats everything the way GCP wants, including with trace contexts, etc.
We've had this in production for months, and it's been pretty great.
You can add this at your main.go
(the rest of the library is about attaching a logger to a context.Context, but you don't need to use that to use the GCP logger)My 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.
All values are supported.
Well, is fmt.Stringer supported? The result might surprise you:
This code produces So the code that uses slog but does not know what handler will be used can't rely on it lazily calling the `String() string` method: half of the standard handlers do that, half don't.If you need more control, you can create a wrapper type that implements `slog.LogValuer`
Usage example: There might be a case for making the expvar types implement `slog.LogValuer` directly.So clearly not all values are supported.
And I know that I can create a wrapper for unsupported types. My problem is exactly that – I don't know what types are supported. Is error supported, for example? Should I create a wrapper for it? And, as a handler author, should I support it directly or not?
Not sure what your definition of "supported" is, but I'm afraid you're going to have to bite the bullet and ... gasp ... read the documentation https://pkg.go.dev/log/slog
Not sure I understand your sarcasm. I read the documentation, source code, handler writing guide, and issues in the Go repository multiple times over two years, and I use slog extensively. Go is my primary language since r60. I think I know how to read Go docs.
Now, please point me to the place in the documentation that says if I can or can't use a value implementing the error interface as an attribute value, and will the handler or something else would call the `Error() string` method.
My definition of "supported" is simple – I could pass a supported value to the logger and get a reasonable representation from any handler. In my example, the JSON handler does not provide it for the fmt.Stringer.
https://pkg.go.dev/log/slog#JSONHandler.Handle
> Values are formatted as with an encoding/json.Encoder with SetEscapeHTML(false), with two exceptions.
> First, an Attr whose Value is of type error is formatted as a string, by calling its Error method. Only errors in Attrs receive this special treatment, not errors embedded in structs, slices, maps or other data structures that are processed by the encoding/json package.
So the json handler more or less works as if you called json.Marshal, which sounds pretty reasonable.
I think you missed the “any handler” part. Currently, the types that my library package could use depend on the handler used by the caller. This limits types to an unspecified subset, making things quite impractical.
That seems to work as expected?
The output of data is handled by the handler. Such behaviour is clearly outlined in the documentation by the JSONHandler. I wouldn't expect a JSONHandler to use Stringer. I'd expect it to use the existing JSON interfaces, which it does.
I'd expect the Text handler to use TextMarshaller. Which it does. Or Stringer, which it does implicitly via fmt.Sprintf.
My problem with that is that it makes it impossible to use slog logger safely without knowing what handler is being used. Which kind of defeats the purpose of defining the common structured logging interface.
> Which kind of defeats the purpose of defining the common structured logging interface.
Does it, though? Why would the log producer care about how the log entires are formatted? Only the log consumer cares about that.
As a producer of the response, if I didn't care about being understood, I would use a made-up language. As a consumer, you may care about understanding my response, but you cannot do anything about it.
Hence the design. The producer coming up with a made up language that makes sense to the producer, but probably doesn't make sense to the consumer — especially when you have many different consumers with very different needs — is far more problematic than the producer providing an abstract representation and allowing the consumer to dig into the specific details it wants.
As with everything in life, there are tradeoffs to that approach, of course, and it might be hard to grasp if you come from languages which different idioms that prioritize producer over consumer, but if you look closely everything about Go is designed to prioritize the needs of the consumer over the needs of the producer. That does seem to confuse a lot of people, interestingly. I expect because it isn't idiomatic to prioritize the consumer in a lot of other languages and people get caught up in trying to write code in those other languages using Go syntax instead of actually learning Go.
[flagged]
A good, if a bit strange, example. A CPI logger wouldn't need to log the same thing as an access logger, but the producer need not care about who is consuming the logs. Consumers might even want to see both and, given the design, can have both.
[flagged]
Certainly logs lose their value if they are wrong. And either approach is ripe for getting things wrong. But the idea is that the consumer is more in tune with getting what the consumer needs right. The producer's assumptions are most likely to be wrong, fundamentally, not having the full picture of what is needed. What is the counter suggestion?
[flagged]
We've banned this account for continually posting unsubtantive comments and ignoring our previous request to observe the guidelines.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
> The key decision is thus between two patterns: using a global logger or using dependency injection. The former is extremely convenient but adds a hidden dependency that’s hard to test, while the latter is more verbose but makes dependencies explicit, resulting in highly testable and flexible code.
Curious how different people handle this. I personally pretty much always pass a logger into function, classes, structs (what have you) so it has the context I need it to. It's a tad more verbose I guess, but it's such a minor lift I've always found it worth it.
In any API service, it's better to handle via dependency injection IMO.
Instantiate all of your metadata once, and then send that logger down, so that anybody who uses that logger is guaranteed to have the right metadata... the time to add logging is not when you are debugging.
> more verbose
I'd say necessarily verbose. Without injection, it is not immediately apparent that something is dependent on something else (in this case a logger) with side effects, which ultimately harms understandability.
I expect by "more verbose" the author really meant "in need of more typing". I am not sure optimizing for less typing ever a good tradeoff. And if you can find good reason to optimize for less typing, you're not going to be choosing a structured language in the first place, so...
Totally agree. I'll suffer with an additional 20 characters of typing. I hadn't even considered the other ways the article goes into, I'd always used a child logger and passed it down, so I'm a bit reassured that I haven't been a _complete_ fool for all these years.
We pass logs in contexts.
Cool article.
I really like structured logs and am pleased the Go team saw the benefits of bringing it into the standard library.
However, I feel like errors should be able to hold slog attributes. It makes for some very useful and easy error logging, especially when the logging takes place far up the execution chain from where the error happened.
This is easily possible with a custom error type and some log functions. I have published on GitHub my small and crude implementation that I use in a few hobby projects, MIT licensed, if anyone is interested. https://github.com/sveinnthorarins/sterlo
I'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!
To guarantee correctness, you must use the strongly-typed slog.Attr helpers. They make it impossible to create an unbalanced pair by catching errors at compile time
I take their point, but given the typical value of most logging lines, this does not seem worth the tax you pay in readability. This is a gripe I have with oTel too --- it really cruds your code up --- but with oTel you're getting long-term value that logging (which is still my go-to o11y) doesn't.
OTel have logging too... https://pkg.go.dev/go.opentelemetry.io/otel/log
and even a slog bridge https://pkg.go.dev/go.opentelemetry.io/contrib/bridges/otels...
I'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.
I 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
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.
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.
I’m not sure I understand what you mean by “magic for config”. You create and configure a logger using slog.New(…). You can use the default logger instead, slog.Default(), which is just a global and has a default config. You can also set the default logger using slog.SetDefault(…).
It’s extremely unmagical in my opinion.
The "magic" is just global state? I agree that I try to avoid global state in my code but it's hardly Spring Boot levels of auto wiring bullshit.