> 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.<p>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.<p>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.<p>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.
The configuration examples are not valid JSON, due to trailing commas. Not a great first impression. <a href="https://github.com/runreveal/kawa#getting-started">https://github.com/runreveal/kawa#getting-started</a><p>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.
If you haven’t read the original grug brained developer essay, treat yourself: <a href="https://grugbrain.dev/" rel="nofollow noreferrer">https://grugbrain.dev/</a>