Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Structured logging with slog

go.dev

Post reply on HN
Print view View original

21–30 of 174 posts

Re: Structured logging with slog

#21

Post by [deleted] »

LambdaComplex wrote: post #10
earthboundkid wrote: post #5

Earlier quoted context omitted.

An iterator type is being actively worked on now. After that presumably the missing data types in the standard library will be filled out (set, deque, a usable heap, whatever other algorithms). After that, who knows. Maybe native bigints? I don’t really see the enum thing happened. Is lack of enums a real problem? Theoretically, it would be convenient, but I can’t say that I see bugs caused by its lack.

Having "type MyType int" and defining a bunch of constants isn't a great replacement for enums. Yeah, it "works," but it still lets the developer forget to check for a possible variant, or you could have an underlying int that doesn't correspond to a valid variant. The addition of enums would move all these runtime checks to compile time.

[deleted]

Re: Structured logging with slog

#22

Post by grose »

mrweasel wrote: post #8

Admittedly I'm not a huge fan of having: slog.Info("hello, world", "user", os.Getenv("USER")) It's a little magical that "user" is a key. So what if you have multiple key-value pairs? Arguably it most likely going to be obvious which is the keys, but having every other value be a key and the rest values seems a little clumsy. I really like Pythons approach where you can have user="value" it makes things a bit more cl…

It’s not without precedence, for example: https://pkg.go.dev/strings#NewReplacer

I don’t mind it. You can use LogAttrs if you want to be explicit.

Although I do wonder if there’s anything tricky with the type system that is preventing something like this from being supported: https://go.dev/play/p/_YV7sYdnZ5V

Re: Structured logging with slog

#23

Post by eska »

mrweasel wrote: post #8

Admittedly I'm not a huge fan of having: slog.Info("hello, world", "user", os.Getenv("USER")) It's a little magical that "user" is a key. So what if you have multiple key-value pairs? Arguably it most likely going to be obvious which is the keys, but having every other value be a key and the rest values seems a little clumsy. I really like Pythons approach where you can have user="value" it makes things a bit more cl…

If you had read more than the introduction you’d have found a paragraph about this in the middle and multiple at the end.

Re: Structured logging with slog

#24

Post by packetlost »

returningfory2 wrote: post #19
packetlost wrote: post #18

Earlier quoted context omitted.

A better interface/API is really what I meant. The performance characteristics are probably worth the tradeoff.

Passing in a map would require an extra allocation for the map memory for each log line. I think the performance would probably not be great?

it depends. I believe map literals are stack allocated if they aren't shared across goroutines or globals.

Re: Structured logging with slog

#25

Post by progbits »

jmarchello wrote: post #13
geodel wrote: post #3

With this another most requested feature is covered by Go. This leaves error handling, enum type which are often asked by users but are not actively being worked on for now.

The lack of Error Handling in Go is a feature, not a bug. See here: https://go.dev/doc/faq#exceptions . I think I'd be disappointed if Try/Catch ever made their way into the language.

Error handling != exceptions.

Step one would bee sum types, so only valid value space can be represented (return value or error, but not both or neither).

Re: Structured logging with slog

#26

Post by geodel »

jmarchello wrote: post #13
geodel wrote: post #3

With this another most requested feature is covered by Go. This leaves error handling, enum type which are often asked by users but are not actively being worked on for now.

The lack of Error Handling in Go is a feature, not a bug. See here: https://go.dev/doc/faq#exceptions . I think I'd be disappointed if Try/Catch ever made their way into the language.

I am not demanding either of these things. Just making general comment based on observing folks.

Re: Structured logging with slog

#27

Post by jmarchello »

progbits wrote: post #25
jmarchello wrote: post #13

Earlier quoted context omitted.

The lack of Error Handling in Go is a feature, not a bug. See here: https://go.dev/doc/faq#exceptions . I think I'd be disappointed if Try/Catch ever made their way into the language.

Error handling != exceptions. Step one would bee sum types, so only valid value space can be represented (return value or error, but not both or neither).

Good point, a poor assumption on my part

Re: Structured logging with slog

#28

Post by 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

Re: Structured logging with slog

#29

Post by gdprrrr »

grose wrote: post #22
mrweasel wrote: post #8

Admittedly I'm not a huge fan of having: slog.Info("hello, world", "user", os.Getenv("USER")) It's a little magical that "user" is a key. So what if you have multiple key-value pairs? Arguably it most likely going to be obvious which is the keys, but having every other value be a key and the rest values seems a little clumsy. I really like Pythons approach where you can have user="value" it makes things a bit more cl…

It’s not without precedence, for example: https://pkg.go.dev/strings#NewReplacer I don’t mind it. You can use LogAttrs if you want to be explicit. Although I do wonder if there’s anything tricky with the type system that is preventing something like this from being supported: https://go.dev/play/p/_YV7sYdnZ5V

Is ordering of the keys guaranteed to be the same as in the literal?

Re: Structured logging with slog

#30

Post by candiddevmike »

Looking for advice: logging for servers/services tends to be different than logging for CLI-based applications. How do folks differentiate them or use slog for them in a generic way? Or does it make sense to have separate logging packages for CLI vs services? CLI tends to be more verbose and procedural vs servers/service based logging which is more errors only unless debug.
Post reply on HN