You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The idea behind defining a service there can exist multiple implementations like opentracing, opentelemetry, honeycomb etcetera. Now we've defined per tracing solution a seperate module, but I think it's a great idea to unify this like github.com/tpolecat/natchez/ does
WDYT?
The text was updated successfully, but these errors were encountered:
IMO that totally makes sense. The first version of the library had that abstraction. However, OpenTelemetry still was in early alpha by then. We would have had to guess half of the API and we needed a working OpenTracing implementation, hence the split. By now we understand the domain much better I guess. We would probably need some kind of modules, as not all functionality is available through all libraries.
OpenTelemetry seems to be getting close to stable release, so IMHO it would be better to focus on adding full support for it, rather than trying to keep additional layer of abstraction for already obsolete OpenTracing/OpenCensus or single vendor standards.
The idea behind defining a service there can exist multiple implementations like opentracing, opentelemetry, honeycomb etcetera. Now we've defined per tracing solution a seperate module, but I think it's a great idea to unify this like github.com/tpolecat/natchez/ does
WDYT?
The text was updated successfully, but these errors were encountered: