Could be because <abbr> doesn't show anything on mobile. Also not having a shorthand in markdown doesn't help with the adoption.

Oh for sure. But even a verbose guidance won't prevent people from taking stuff too literally if that's what they want. As humans, we're not wired to deal with "it depends" all too well.

If you understood that intuitively from "best practices", then it’s doing its job without being obnoxiously verbose.

While it’s easy to pick on existing terminologies for being vague, I think as long as we have a shared understanding of the terms, we don't need to reinvent every little thing.

It would be cool if we had something that could keep sending data to Sentry but generated the spans as a side effect. That way, we could make the Sentry DSN a no-op and keep generating the traces before refactoring to weed out the SDK.

AFAIK there's no drop-in replacement. We did it by intercepting in the SDK's BeforeSend and passing the ctx via event hints.

Inside BeforeSend, we manually parsed the sentry event & called otel's span.RecordError. It wasn't pretty.

docs.sentry.io/platforms/go...

docs.sentry.io/platforms/go...

Most posts in LinkedIn were vapid word manure spewed up by corporate zombies long before the emergence of LLMs.

These tools have just lowered the required activation energy to take part in this circus.

Even for traces, the current experience isn't much better than zipkin era.

It's true that greenfield projects are more benefitted from LLMs.

However, what I'm seeing is, people bootstrap new projects w/ agents & have a lot of fun.

But once the size & scope grow, the agents become less effective & their human operators have less understanding of the overall codebase.

This is true at Doordash too, at least in the foundation team where I work.

In giant brownfield projects, most of these agents are less useful as the context window gets filled even before they understand the task at hand.

I come from datadog stack and not a big fan of LGTM so far. It's all so janky.

True but then

> copying a Go struct should generally be taken with a grain salt,

This does indicate a "general" pattern. Go vet now catches the mutex copy issue, so that's less of an issue now

It's not even older toolset. More like new o11y platform built from scratch with LGTM stack.

As it happens in a huge company, we start with Datadog and then once that gets out of hand, we try other vendors before building a janky version in house with 1/10 of the vendor's resource.

Passing small structs (<128 bytes) by value is fine other than in tight loops. They get copied over to the stack and the whole operation is wicked fast.

Passing small struct as pointer reduces the copied over amount but still incurs heap traversal and gc tracking costs.

More teams do replace them with SLOs but when things go south, it's almost always back to looking at dashboards.

This manually correlating one monitor to another is a big pain and modern metrics and traces haven't been able to alleviate that as much.