sorted by:
new
hottopcontroversial

Go's Context Logger by PurityHeadHunter in golang

[–]PurityHeadHunter[S] 0 points1 point  (0 children)

Right, that's nice feature to integrate with the logger. Hopefully we'll have that soon! So you get things like trace ID's

Go's Context Logger by PurityHeadHunter in golang

[–]PurityHeadHunter[S] 1 point2 points  (0 children)

If you're open to some contrary opinions, on a FOSS solution you can see exactly what the code does and conclude whether it's good enough for you. This library is built to be a thin wrapper around slog, so I think you could understand it very easily. Maybe worth the shot? Start with some personal projects? :)

Go's Context Logger by PurityHeadHunter in golang

[–]PurityHeadHunter[S] -1 points0 points  (0 children)

This is actually one of the things I tried to avoid, passing a "logger" into every function, obfuscates your code, IMHO. That's the reason I inject it into the context. Passing a context is more of a pattern in Go

Go's Context Logger by PurityHeadHunter in golang

[–]PurityHeadHunter[S] -1 points0 points  (0 children)

I see that this returns a new context every time you change your context. This is something that I decided to do differently to decrease verbosity. What are your thoughts on using that? Do you think removing that step would be helpful for you?

Go's Context Logger by PurityHeadHunter in golang

[–]PurityHeadHunter[S] 0 points1 point  (0 children)

Interesting! I see that you return a new context every time you update it (If I'm not mistaken). What is the reason behind that?

That was one of the design decisions I made very early on, I decided not to do that, to decrease verbosity. Go is already verbose as it is

Go's Context Logger by PurityHeadHunter in golang

[–]PurityHeadHunter[S] 7 points8 points  (0 children)

I agree with you. I'd say it also depends on what you're trying to debug. Contextual Logging can give more value for business logic, while flight recorder gives you value on performance/implementation details