If we ignore the proposal, this gives at least an awesome overview of the state-of-the-art of logging in go. That was the best part. Thanks for the heads up!
- The existing log package has been in the standard library since the release of Go 1 in March 2012. It provides formatted logging, but not structured logging or levels.
- Logrus, one of the first structured logging packages, showed how an API could add structure while preserving the formatted printing of the log package. It uses maps to hold key-value pairs, which is relatively inefficient.
- Zap grew out of Uber's frustration with the slow log times of their high-performance servers. It showed how a logger that avoided allocations could be very fast.
- zerolog reduced allocations even further, but at the cost of reducing the flexibility of the logging backend.
- All the above loggers include named levels along with key-value pairs. Logr and Google's own glog use integer verbosities instead of named levels, providing a more fine-grained approach to filtering high-detail logs.
Other popular logging packages are Go-kit's log, HashiCorp's hclog, and klog.
Anyways, would love to hear more about your clever queries, even if it's OT.
Logger* OpenLog(char*);
Table* MakeLog(Logger*, unsigned level, unsigned N, char* colNames, ColType *colTypes);
LOG(Table, Level, ...);
The branch to select log-level is trivial compared to the append cost. There's a few "backends" built in to the API: (1) a text-streaming version that just writes a text log; (2) a "bucketing" version that boils the calls to `MakeLog` down to accumulating buckets (with optional stack tracing); and, (3) journaling to a SQLite DB (with optional stack tracing).
Also, can you describe the queries you run against this SQLite? Is it interactive use or do you have any jobs or charts that are powered by it?
So very interested in this whole approach - if you have any posts or links to read more happy to see em!