-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
fasthttp
Fast HTTP package for Go. Tuned for high performance. Zero memory allocations in hot paths. Up to 10x faster than net/http
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
I also think there's a lot more that can be done if your focus is on "human readable" beyond just "logging with colors". I've played around with this myself while trying slog on for size and inspired by humanlog. Things like visually distinguishing the message, while also visually minimizing the timestamp with color and marking keyvals differently to the main message and even allowing for indentation and grouping of output are important considerations when you know you have a TTY and don't care about being machine-readable or even particularly fast. In that regard, I think that charmbracelet/log could be doing more.
To date I think tracing (Rust) did this best. That is just a facade that decouples producers from subscribers in a neat API. The official tracing-subscriber has a fantastic console format that ticks all the boxes we're discussing here, in fact it's similar to the screenshot in OP, and it also has a tidy JSON format not too far off from Zap or Zerolog. I found it very easy to wrap a subscriber to tweak the format for console readability even more. But if you didn't like any of that, you could use another subscriber without changing any producer code at all, because it all goes through the facade.
As I said in another comment, I think net/http is a good cautionary tale here. It was designed to be easy to use, and then grew organically, but performance never seems to have been a goal. fasthttp solves this, but bifurcates the ecosystem and passes on those costs to everyone who uses it. If net/http had been designed with performance in mind, this could have been avoided. net/http can't be removed or optimized, so this is a situation the Go ecosystem is effectively stuck with forever. At best, a faster version may end up in the std lib, just like netip is more modern and faster than net but the ecosystem is still bifurcated and adoption of the new package has been slow.