FWIW tracing in Go is primarily made more difficult by having explicit context propagation and no helper to auto-close a span based on scope. If you use Python or .NET for example, it's implicit and you can "just create some spans" like you would a structured log somewhere in your app, then use built-in language constructs to have it handle closing for you.

Sure. If it was a different language, or a different otel library, my opinion would probably be different. I do not think it's realistic to replace logging with otel in Go, though.

I think it's an inclusive OR here. When logging stabilizes in the Go SDK (which will be a while, perhaps a year) the idea will be that you can keep all your existing logging and then start to add tracing judiciously so they're easily correlated with requests. I think the juice is worth that particular squeeze for more folks at least.

From there I would personally advocate for adding more manual traces rather than more logs, but it's understandable if it's a heavier lift to pass context around all the time. The more options the better.

For web-style application code my experience writing Go code says that you totally can stop using logs and just use traces and have just as much visibility into a running process, if not more.

For library code or other deployment models I’m not sure - it’s not something I’ve had a need to experiment with

.Net has task-local storage which is pretty amazing and Seri log made great use of it(my all-time fav structured log lib).

But iirc task local is a perf concern, and JavaScript has yet to have anything comparable that's ubiquitous(nodejs async hooks though so one day maybe).

So, explicit contexts for Go and JavaScript unfortunately.

JS does have convenience APIs in the form of startActiveSpan and getActiveSpan that take care of most of the pains here. There's likely some scenarios where you can't use these (e.g., instrumenting a tool must use the sdk-trace-base package) but I think in most cases they help a lot. Go doesn't have these kinds of convenience APIs though.

...the helper like WithCancel/WithDeadline ?

What annoys me about otel is that it seems to require direct live connections. I'd much rather just add the tracking keys / spans / whatever to my logs and parse them out of there later, but no standard lib / app / process seems to like that idea. I have no intention of adding extra sockets to my requests when I can just dump everything to the logs as JSON.

So that's what I do, but instead of relying on otel tools, I have custom queries I run against elasticsearch (or grep syslog) using my trace tags. Works great. No multi-process visualizations but i can make my way through a process chain quickly enough

That's why you have otel logging: https://github.com/open-telemetry/opentelemetry-specificatio...

I've played with trying to create an idiomatic wrapper for their Go module precisely because of this reason, but then didn't find time to continue with this.

https://github.com/henvic/tel