4 ms·
If slog needs to avoid virtual calls or boxing or whatever else for reasons of performance, I guess I feel very strongly that it should do so in a way that does
by kiitos 3y ago
If slog needs to avoid virtual calls or boxing or whatever else for reasons of performance, I guess I feel very strongly that it should do so in a way that doesn't impact users, and shouldn't let these concerns influence the API design.
- morelisp 3y ago"Ignore performance when designing your API" is an obvious non-starter. I don't think you're serious. More specifically, users want the surface area Logger has. They do not want a single function with a complex object specification, just like they don't want a function per type.
- kiitos 3y agoThere is obviously an enormous difference between "don't let performance influence your API (to become awkward or nonidiomatic)" and "ignore performance when designing your API".
- morelisp 3y agoBut you've offered no actual criteria why the API is bad! Again, most logging users want something to handle nested record contexts for them and per-level methods, most logging implementers want a minimum number of entry points, and that's exactly what this API offers. (It's definitely not zerolog-style where it sacrifices ease of use for performance.)
- kiitos 3y agoStructured logging means logging where discrete events are sets of key=val pairs, and nothing more. What is a record context? What is a level? These are concepts built on top of a structured logger, which manifest as specific key=val pairs in a given structured log event. They don't need -- and shouldn't have! -- first-order representation in a low-level structured logger API. What is an entry point? If I'm writing some structured logger implementation, I expect that I should need to provide precisely one method: func (x *MyThing) Log(<set of key=val pairs>) error Anything more is cruft.