Collab opportunity

[janstenpickle]

Hey @rossabaker I'm the creator and one of the maintainers of https://github.com/trace4cats/. The core tracing code is native Scala, with translations to various different backends. For the tracing portion of this project I was wondering if there might be an opportunity to share a common kernel? I haven't had a good look through this codebase yet, but my gut feeling is by both trying to do native scala implementations of at least the tracing part, we can share some code. Let me know! 😄

[armanbilge]

See also discussion in #11 :)

[iRevive]

Perhaps the project can be more modular.

For example, http4s-metrics can depend only on otel4s-metrics module, since it does not care about tracing. And another lib can depend on otel4s-tracing and ignore metrics.

As of now, I can think of the following structure:

1. otel4s-base - Attribute, AttributeKey, AttributeType and some shared internals
2. otel4s-metrics - depends on otel4s-base
3. otel4s-tracing - depends on otel4s-base
4. otel4s-core - aggregates otel4s-base, otel4s-metrics, otel4s-tracing

[janstenpickle]

@iRevive that makes a lot of sense to me!

[rossabaker]

Sorry for the slow reply. It's been a slow reboot from vacation...

I like @iRevive's module boundaries. OpenTelemetry also includes logging, but it's the least exciting concern vs. existing solutions. That's a distant third, but could sit next to otel4s-metrics and otel4s-tracing in this scheme.

One goal for this project is for its naming to adhere closely to the OpenTelemetry standard. I work in a polyglot shop, and it's helpful to have a shared vocabulary for the core Otel concepts. As far as trace4cats goes, would those otel4s-base types be useful?

I would imagine that trace4cats could target otel4s-tracing, but it's not clear what that would bring over its existing opentelemetry backend, at least until someone is ambitious enough to write a backend that doesn't depend on the JDK. (As a JVM person, I don't have any plans to implement that, but I know the Scala.js people would like it, and I don't want to foreclose the opportunity.)

[janstenpickle]

Sorry for the slow reply. It's been a slow reboot from vacation...

No problem at all, I hope you had a good time off!

As far as trace4cats goes, would those otel4s-base types be useful?

Yes, I think at very least we should definitely share a base.

I would imagine that trace4cats could target otel4s-tracing, but it's not clear what that would bring over its existing opentelemetry backend, at least until someone is ambitious enough to write a backend that doesn't depend on the JDK

Yeah, that's fair. My main motivation with trace4cats was to eliminate the requirement for a dependency on gRPC, which with all the reflection the Java gRPC library does, was wreaking havok with dependency hell at $work where we also have to depend on Google libraries for working with GCP services. For me this is motiviation enough to create a Scala/JVM cats-effect based otel4s-tracing backend, assuming the pieces fit and would be an interesting exercise in aligning the two projects.