Verbosity of addAttributes vs. Natchez

[rossabaker]

I'm staring at a diff that looks like this:

-                  NatchezTrace[F].put(
-                    reasonKey -> "header validation failed",
-                    "header" -> header.value,
-                  )
+                  Tracer[F].currentSpanOrNoop.flatMap(_.addAttributes(
+                    Attribute(reasonKey, "header validation failed"),
+                    Attribute("header", header.value),
+                  ))

The philosophy has been to adhere to the Otel spec, which I think it good. But it's awfully low level. I'm wondering how early adopters are dealing with this.

• Staying at this low level?
• Using some helper I overlooked?
• Rolling their own helpers?

I think the minimalism is great in libraries: less surface area to cause breaking changes. I'm concerned about selling this API to app developers without a bit of sugar, though.

[iRevive]

At $work, the team almost always makes a wrapper over Tracer to provide a more expressive API.

I guess we can forward the majority of the Span methods (e.g., addAttributes, addEvent, recordException, etc.).

[rossabaker]

The two things that stick out as noisier in my example are:

• The need to flatMap
• Attribute vs. ->

Forwarding methods are trivial and don't leave much room for interpretation, but if two smart Scala developers tried to adapt varargs tuples to Attributes, I bet we'd get two incompatible solutions. I'm a little scared to include anything opinionated that isn't an Opinion Of The Specification.

[iRevive]

We can make a separate module to manage extensions there. e.g.: "org.typelevel" %%% "otel4s-syntax" % "x.y.z.".

package org.typelevel.otel4s.trace

object syntax {

  implicit class TracerOps[F[_]](private val tracer: Tracer[F]) extends AnyVal {
    def addAttributes(attributes: Attributes)(implicit F: FlatMap[F]): F[Unit] = 
      tracer.currentSpanOrNoop.flatMap(_.addAttributes(attributes))
  }

}

The core module will comply with the spec, and we can still offer some suggar. But keeping an import around could be annoying for a user.

[rossabaker]

I had a nice chat with @NthPortal yesterday, who reminded me of the benefits of defining AttributeKeys as constants and applying them. It's even a little more verbose than the tuple for one-off attributes, but it's a win for repeated attributes, and so many of them are already in the library we provide. I think perhaps the key here is just learning to think a little bit more about otel4s in its own right, and not thinking in terms of making it look like a word-for-word translation from Natchez.