4 ms·

The majority of Golang devs actually do work on web services, API's, or libs/frameworks that would benefit from a standardized structured logging interface. So

by atsjie 4y ago

The majority of Golang devs actually do work on web services, API's, or libs/frameworks that would benefit from a standardized structured logging interface. Source: https://go.dev/blog/survey2022-q2-results https://go.dev/blog/survey2022-q2-results (scroll almost to the bottom) For the audience of this proposal it's probably fairly evident what the advantages of standardization would be. Also you argue quite strongly about the poor API design decisions being made; while you similarly admit not having worked with such tools or with web services in Golang general. That's odd.

svnpenn 4y ago
I don't work with servers much, but I do have extensive experience in Go. I know a bad API when I see one. strings.Replacer [1] uses the same syntax, and several others have commented in the discussion about it being a bad idea. 1. https://godocs.io/strings#Replacer https://godocs.io/strings#Replacer
- xani_ 4y ago
  From what I've skimmed the most problems seem to be "golang's type system won't allow expressing all of that on compile time so it will be costly" and I don't think that can be sensibly fixed in logging package > I know a bad API when I see one. strings.Replacer [1] uses the same syntax, and several others have commented in the discussion about it being a bad idea. What's wrong with it ? Never used it. But I think the complaints has been about wasting time for runtime type handling and Replacer doesn't have that problem.
  - Joker_vD 4y ago
    The main performance problem is with "kvs ...any" parameter in the Logger's functions because it allocates lots of stuff: the array itself, and then the wrappers around the values. I've tried to use something like this in a central loop of a CPU-emulator to trace every instruction executed and IIRC it slowed things about 3x times down. The only thing you can do to escape this cost is if logging.Level() >= logging.DEBUG { logging.Logger.Debug(...) } but it's ugly and can't be abstracted away. And yes, I've put several of such guards in the several hot paths of some actual production code base and seen about 25% speed up after that edit.
  - jen20 4y ago
    > What's wrong with it ? It relies on lining up pairs of values in a way that cannot be checked by the compiler rather than having dedicated functions that ensure they are kept together. This is the fundamental difference between bad logging libraries (like klog, hclog etc) and good logging libraries (like zerolog).
    - xani_ 4y ago
      I guess simplest fix for that particular one would be accepting `map[string]string` but that won't exactly work for the any type, and you can't easily add more. Maybe `...map[string]interface{}` but we're back to "the overhead is kinda shit"

by atsjie 4y ago

svnpenn 4y ago

I don't work with servers much, but I do have extensive experience in Go. I know a bad API when I see one. strings.Replacer [1] uses the same syntax, and several others have commented in the discussion about it being a bad idea. 1. https://godocs.io/strings#Replacer https://godocs.io/strings#Replacer

xani_ 4y ago
From what I've skimmed the most problems seem to be "golang's type system won't allow expressing all of that on compile time so it will be costly" and I don't think that can be sensibly fixed in logging package > I know a bad API when I see one. strings.Replacer [1] uses the same syntax, and several others have commented in the discussion about it being a bad idea. What's wrong with it ? Never used it. But I think the complaints has been about wasting time for runtime type handling and Replacer doesn't have that problem.
- Joker_vD 4y ago
  The main performance problem is with "kvs ...any" parameter in the Logger's functions because it allocates lots of stuff: the array itself, and then the wrappers around the values. I've tried to use something like this in a central loop of a CPU-emulator to trace every instruction executed and IIRC it slowed things about 3x times down. The only thing you can do to escape this cost is if logging.Level() >= logging.DEBUG { logging.Logger.Debug(...) } but it's ugly and can't be abstracted away. And yes, I've put several of such guards in the several hot paths of some actual production code base and seen about 25% speed up after that edit.
- jen20 4y ago
  > What's wrong with it ? It relies on lining up pairs of values in a way that cannot be checked by the compiler rather than having dedicated functions that ensure they are kept together. This is the fundamental difference between bad logging libraries (like klog, hclog etc) and good logging libraries (like zerolog).
  - xani_ 4y ago
    I guess simplest fix for that particular one would be accepting `map[string]string` but that won't exactly work for the any type, and you can't easily add more. Maybe `...map[string]interface{}` but we're back to "the overhead is kinda shit"