4 ms·
Kawa: The Event Processor for the Grug Brained Developer
- SeanLuke 3y agoUgh. Just a tiny bit of googling would have informed them that Kawa is the name of a well-regarded scheme implementation in Java.
- eigenket 3y agoUgh. Just a tiny bit of googling would have informed the scheme people that kawa is the Polish word for coffee.
- imagine2024 3y agoBased 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?
- lloydatkinson 3y agoWhich is perfectly fine for that because Java is a type of coffee?
- lelanthran 3y agoAnd scheme is not an event processor.
- deleted 3y ago[deleted]
- msm_ 3y agoActually it means quite a few things in various languages: https://en.wiktionary.org/wiki/kawa https://en.wiktionary.org/wiki/kawa
- lioeters 3y agoUgh. Just a tiny bit of googling would have informed the Polish people that قَهْوَة (qahwa) is the Arabic word for coffee.
- eigenket 3y agoThat'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.
- gjvc 3y agoYes, 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.
- tveita 3y agoIt's Japanese for river, presumably following the same naming logic as e.g. Flume.
- steve_adams_86 3y ago> 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.
- baz00 3y agoI'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.
- Jochim 3y agoGood 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.
- doitLP 3y agoIf you haven’t read the original grug brained developer essay, treat yourself: https://grugbrain.dev/ https://grugbrain.dev/
- fl0ki 3y agoThe configuration examples are not valid JSON, due to trailing commas. Not a great first impression. https://github.com/runreveal/kawa#getting-started 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.
- ejcx 3y agoThe 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.
- fl0ki 3y agoSerious 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-comments.html#why-not-toml-instead https://nigeltao.github.io/blog/2021/json-with-commas-commen... And while we're at it: https://www.arp242.net/json-config.html https://www.arp242.net/json-config.html https://dzone.com/articles/why-json-isnt-a-good-configuration-language https://dzone.com/articles/why-json-isnt-a-good-configuratio... https://revelry.co/insights/development/json-configuration-file-format/ https://revelry.co/insights/development/json-configuration-f...