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

▲

roncesvalles 2 days ago | parent | next [-]

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.

	▲	sethammons 2 days ago \| parent [-]
		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.

▲

catlifeonmars 2 days ago | parent | prev | next [-]

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.

▲

gdbsjjdn 2 days ago | parent | prev [-]

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.