4 ms·
Show HN: Phuslu/Log – Structured Logging for Humans
- kissgyorgy 6y agoOoooh, stop the "for Humans" insult already! It suggests that all other libraries are not "for humans" somehow. It's very offensive to everybody. Terrible branding.
- marvinblum 6y ago"No Code Logging Library" would be even better ;)
- OJFord 6y agoYes, 'for Go' would be much more informative here. It doesn't even make that clear in the readme, had to scroll until I got to an example that included imports to tell.
- stevekemp 6y agoMarketing. First of all it was "made with love", then it was "for humans". Next year it will be something else.
- remram 6y agoAnd the selling point of structured logging is that's it's more friendly for computers to consume. "Structured logging for humans" sounds like unstructured logging...
- The_rationalist 6y agoIt's still a valuable information, it claims that they focus on user friendliness and fight clutter/cognitive overhead / boilerplate. How would you alternatively communicate this?
- aldanor 6y ago"... - Go Logging Made Simple" or whatever else. There's many ways to communicate this without the stupid "for humans" tag.
- ViViDboarder 6y agoEspecially when it logs as JSON by default. That’s certainly not for humans but great for machines. I see it can log on a more human friendly console format as well though.
- ssss11 6y ago{ what: doyou, mean: jsonis, not: forhumans }
- ViViDboarder 6y agoWrap those strings with quotes so it can be more “readable”.
- cube2222 6y agoFor people interested in this, there's a great presentation, The Hunt For a Logger Interface[0]. It describes how approaches to structured logging evolved over the years. I especially like the idea of using closures as logging context values, which get evaluated every time they're printed, it often greatly simplifies contextual logging. [0]: https://go-talks.appspot.com/github.com/ChrisHines/talks/structured-logging/structured-logging.slide#1 https://go-talks.appspot.com/github.com/ChrisHines/talks/str...
- jeffbee 6y agoThese don't seem like very practical interfaces to me. One of the nice features of glog is when you log at a high severity it flushes all the output buffers and syncs the files. For this to work, the lowest level of glog has to be aware of the severity. If you cut off that knowledge in the middle of your interface (by serializing the log early, and passing down []byte) then you don't have the information you need at the right place and time. This library author should have realized their error when they needed to add the parseLevel function to get the severity back out of the formatted output. Aside from the weird interface, this library is pretty cavalier about unix file i/o. This function will never notice that all its writes are failing. https://github.com/phuslu/log/blob/master/file.go#L67-L96 https://github.com/phuslu/log/blob/master/file.go#L67-L96
- marvinblum 6y agoAlso little things like the w.mu.Unlock() at the end of the function instead of using defer show that this was probably written by (Go) beginners.
- atombender 6y agoThis seems like an alternative to Zerolog, with some very small performance improvements. I don't understand why you wouldn't just improve Zerolog, or at least (if the original authors don't like your changes) just fork it. For me, while this looks decent, it doesn't justify an entirely new project, nor do I see any particular reason to switch. Personally, I wish there was more focus on assimilating context.Context. While I dislike Context for its virulence in codebases, it's a necessary evil at this point. Correlating log statements with some request and following the logic flow (not just within a single app, but across apps) becomes really important in complex systems. The only way to really accomplish this is to flow the logger through Context. You should never instantiate a new logger except at the root of the program.