Kawa: The Event Processor for the Grug Brained Developer | Hacker News Reader

Kawa: The Event Processor for the Grug Brained Developer

blog.runreveal.com

35 pointsejcx18 comments

> OpenTelemetry is a project that aims to standardize all telemetry collection, but by trying to please everyone and make something idiomatic for all languages the result is a bit of a hot mess.

Huh. I’m glad it isn’t just me. I’ve fallen over OT more than a few times. Sometimes seemingly trivial things would take embarrassingly large amounts of trial and error, and I’d often be left with the sense that I’m not totally clear on what I’m doing, why, and if my solutions are correct for the logging I want to do.

I’m perfectly willing to admit that I don’t know what I’m doing, but I guess in some sense I’m glad I’m not the only one.

One time I needed to deploy a rust-based api that serviced a React-based front end, and getting telemetry to work across both on GCP was a hellish nightmare. By the end I sincerely didn’t know why it started working. Dark times.

I've been heel dragging for over a year on OpenTelemetry for this reason. The org doesn't need it either. They saw something shiny and want it for no rational reason other than they think everyone else is doing it.

Realistically they need to focus that energy on more important things like maintenance and quality rather than shovelling more crap into the inferno that has to be maintained.

Good telemetry is an absolute game changer to be fair.

The annoying thing about OpenTelemetry is just how underbaked/rudimentary it is, and how opinionated the implementations are.

For C#, I consider Microsoft's Application Insights to be the gold standard. You get per request tracing, stack traces, hot paths, dependency operations etc. with absolutely no setup on your part.

I was looking for an alternative since my current place is on AWS and OpenTelemetry seemed like a flexible, Terraform-like alternative to the platform specific SDKs.

It's not that simple though... AWS doesn't provide any direct sinks to their services, instead you must send it to a collector running in a sidecar container, or if it's a lambda: create a custom layer.

X-Ray's surfacing of the traces sucks as well. It'll only show traces in 6 hour ranges. Hopping between 5 different products trying to find the right metric is not an enjoyable experience.

Reasonable telemetry i.e. logging which can be correlated across services, is probably good enough. I think we're hitting 15,000 logs a second so even sampling OT becomes financially infeasible.

The configuration examples are not valid JSON, due to trailing commas. Not a great first impression. https://github.com/runreveal/kawa#getting-started

I see it's because they use their own config loader library that uses hujson. Why even use the human-unfriendly JSON format if you're also going to make it machine-unfriendly by not conforming? If nothing else, why not at least acknowledge that in the documentation which still calls it JSON? If this is what Grug Brained development looks like, they can keep it.

The json parsing library that parses the config file allows either syntax. That was intentional since we get in the habit as go programmers of ending lines in structs/maps with commas, it's just for convenience.

Serious question though, why use "JSON" at all then? You can just admit it's JWCC, which is fine, at least that's a distinct term -- but even that's not a spec, it's just a blog post that very few people even know about. Even that same blog post endorses using TOML, the spec generally preferred for things that may need to be human-edited. It meets humans half-way a lot better than even JWCC, which is the kind of practicality I think even Grug would prefer.

https://nigeltao.github.io/blog/2021/json-with-commas-commen...

And while we're at it:

https://www.arp242.net/json-config.html

https://dzone.com/articles/why-json-isnt-a-good-configuratio...

https://revelry.co/insights/development/json-configuration-f...

If you haven’t read the original grug brained developer essay, treat yourself: https://grugbrain.dev/

Ugh. Just a tiny bit of googling would have informed them that Kawa is the name of a well-regarded scheme implementation in Java.

Ugh. Just a tiny bit of googling would have informed the scheme people that kawa is the Polish word for coffee.

Which is perfectly fine for that because Java is a type of coffee?

And scheme is not an event processor.

Actually it means quite a few things in various languages: https://en.wiktionary.org/wiki/kawa

Based on the people listed as contributers to Kawa, I see several Polish people there. Perhaps they chose that name intentionally because both Java and Kawa has the same coffee connection?

Ugh. Just a tiny bit of googling would have informed the Polish people that قَهْوَة‎ (qahwa) is the Arabic word for coffee.

That's a bit more challenging since Google didn't exist yet when Polish people started using the word kawa. On the other hand there were certainly people around who knew.

Yes, why people don't think to check and change this, for their own project's visibility/searchability, shows how bad people are at PR / window dressing.

It's Japanese for river, presumably following the same naming logic as e.g. Flume.

Reply on news.ycombinator.com