I don’t think this is that complicated. The go team can change the implementation of both log to delegate to slog with some defaults.
slog already has the infrastructure to support additional handlers which I think is all that is needed to support custom requirements - aka side effects - of external libraries. > On Apr 1, 2025, at 2:29 AM, Mike Schinkel <m...@newclarity.net> wrote: > > >> On Mar 30, 2025, at 3:45 AM, Andrew Harris <harris.and...@gmail.com >> <mailto:harris.and...@gmail.com>> wrote: >> >> > Can you link that discussion, please, for those of us who may have not >> > seen the discussion nor be able to find the specific discussion via search? >> >> https://github.com/golang/go/issues/56345 (super-thread) >> https://github.com/golang/go/issues/58243 (what to do about context) > > Thank you for those links. > >> > it still does not solve the inconsistency problem across 3rd party >> > packages used by a Go app >> >> FWIW I think "Imported by" numbers show adoption of slog has been pretty >> good - I am going by memory but slog is up to 40k importers > > Given that log has been "imported by" 1,270k times — or +30 times more than > slog — and I'd say we are a very long way from slog being defacto-standard, > unfortunately. > >> In theory custom wrapping of slog Handlers is flexible enough to integrate >> diverging opinions between dependencies of a project. I don't know how >> frequently that is leveraged in solutions. > > Depending on how slog is implemented in a project, yes that is true. And I do > see slog was a great improvement over log. > > OTOH slog was a necessary but still not sufficient step for developers to > gain full control over logging in their apps. Additionally it would be > helpful if Go made it possible to wrest control of logging from a package > used by an app and give that control back to the app developer. A good place > to start would be for all those packages that use log. > > -Mike > > P.S. One simple approach, at least for log, might be for the Go team to add > (something like) a log.WriterFilter package var of type > func(io.Writer)io.Writer that could be used together with log.SetOutput() by > an app or package and optionally (and less simply) some way to ensure > log.WriterFilter is assigned by an app or package before log.SetOutput is > called directly or indirectly by any other package in an init() or package > var assignment. #fwiw > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion visit > https://groups.google.com/d/msgid/golang-nuts/5EA9AFEA-D954-46B5-BE78-1550F7E52D94%40newclarity.net > > <https://groups.google.com/d/msgid/golang-nuts/5EA9AFEA-D954-46B5-BE78-1550F7E52D94%40newclarity.net?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/163710C1-44EC-4568-802C-D3AD5C07BBB2%40ix.netcom.com.
