[zknill]

The new structured logging library is a great addition, its nice to have structured logging in the standard lib.

It's easy to get started with log/slog and one of the built in handlers, but as soon as you want to change something the library design pushes you towards implementing an entire handler.

For example, if I want the built in JSON format, but with a different formatting of the Time field, that's not easy to do. It's not obvious how to change the built in handler.

I wrote slogmw[1] to solve this problem. It's a set of middleware and examples that make it easy to make small changes to the built in handlers without having to write a whole new handler from scratch.

[1] https://github.com/zknill/slogmw

[klabb3]

> but as soon as you want to change something the library design pushes you towards implementing an entire handler.

Yes, it annoyed me to no end. But OTOH I think it may be wise of them to see what the ecosystem finds and provide more convenience later. After all, it's std we're talking about, and this takes time to get right.

I'm personally missing:

- A goddamn default no-op/nil logger, that can be declared before initialized in e.g. structs.

- Customization to TextHandler for changing format easily, and omit keys (AIUI ReplaceAttr cannot omit stuff like `time="..."` on each line), which is critical since CLI screen real estate is incredibly sparse.

- (Controversial) but I would like opinionated logger initialization guidance for package authors, so that you get consistency across the ecosystem. Doesn't have to be exactly one way, but say.. two ways? E.g. a package-global and a struct-initialized version? Right now, people are even confusingly wondering if they should accept slog.Handler or *slog.Logger.

[numbsafari]

Nice middleware package.

I have to admit, the `log.InfoContext(ctx,...` style of redundancy that permeates the standard lib at this point is really gross, especially given that the most common use case for go is going to have contexts everywhere.

[yencabulator]

The -Context suffix is only needed when something existed before Context was created. New stuff should be just `foo.Bar(ctx, ...)`

[numbsafari]

Isn't slog, like, completely new as of this release?

[yencabulator]

Yes. Then it having separate -Context variants means they really wanted to provide both, and not just the context one.

[yashap]

Go’s decision to not support function overloading leads to a tonne of really ugly APIs. Obviously every decision in language design is a tradeoff, but IMO they made the wrong call here.

[philosopher1234]

I'm not sure how I feel about this. What are the actual consequences of these apis being "ugly"? Like, why does that matter?

[numbsafari]

To me, at least, it is like listening to a person who constantly says "uh..." while talking. Occasionally, sure fine. But it's so pervasive in commonly used APIs that it becomes annoying.

Let's be clear: this is just a peeve of mine.