> The core issue is that, with otel, observability platforms become just a UI layer over a database. No one wants to invest in proper instrumentation, which is a difficult problem, so we end up with a tragedy of the commons where the instrumentation layer itself gets neglected as there is no money to be made there.
I don't think it's fair to say "no one wants to invest in proper instrumentation" - the OpenTelemetry community has built a massive amount of instrumentation in a relatively short period of time. Yes, OpenTelemetry is still young and unstable, but it's getting better every day.
As the article notes, the OpenTelemetry Collector has plugins can convert nearly any telemetry format to OTLP and back. Many of the plugins are "official" and maintained by employees of Splunk, Datadog, Snowflake, etc. Not only does it break the lock-in, but it allows you to reuse all the great instrumentation that's been built up over the years.
> The core issue is that, with otel, observability platforms become just a UI layer over a database.
I think this is a good thing - when everyone is on the same playing field (I can use Datadog instrumentation, convert it to OTel, then export it to Grafana Cloud/Prometheus), vendors will have to compete on performance and UX instead of their ability to lock us in with "golden handcuffs" instrumentation libraries.
Glad I'm not the only one with that issue. I ended up connecting a Bluetooth controller to my Steam Deck because holding it hurt my wrists so much. At that point, why bother with the thing?
I do the same with my Switch 1— just set the thing up with its kickstand on the tray table and use a normal pad. No amount of slide-on grips or whatever else really make the joycons usable for more than a few minutes with adult hands.
If the SVG being linked to is hosted by GitHub, they could make arbitrary changes before serving it to the browser.
IIRC, I uploaded an SVG in a GitHub comment and the resulting image had some of its interactive functionality removed. Of course, that situation is slightly different since the file was uploaded in a comment and not as part of a Git repo... but still.
By the look of it, the feeling I get is that a decent and convenient syntax proposal has been bikeshedded into rejection. Some particular form of keyword arguments at invocation would definitely make quite a few of my scripts more readable.
> I wish tree-sitter had an official higher level API that allowed processing and pattern matching for use cases other than those required for text editors.
Is the pattern matching API not sufficiently high level? In my experience, it's a huge improvement over implementing visitors for everything.
I don't think it's fair to say "no one wants to invest in proper instrumentation" - the OpenTelemetry community has built a massive amount of instrumentation in a relatively short period of time. Yes, OpenTelemetry is still young and unstable, but it's getting better every day.
As the article notes, the OpenTelemetry Collector has plugins can convert nearly any telemetry format to OTLP and back. Many of the plugins are "official" and maintained by employees of Splunk, Datadog, Snowflake, etc. Not only does it break the lock-in, but it allows you to reuse all the great instrumentation that's been built up over the years.
> The core issue is that, with otel, observability platforms become just a UI layer over a database.
I think this is a good thing - when everyone is on the same playing field (I can use Datadog instrumentation, convert it to OTel, then export it to Grafana Cloud/Prometheus), vendors will have to compete on performance and UX instead of their ability to lock us in with "golden handcuffs" instrumentation libraries.