Should metrics API be developed for golang 1.18

[bogdandrutu]

It looks like golang 1.18 will support generics (see https://go.dev/doc/tutorial/generics). With that the need of "Number" for example as a public type is a bit unclear, and probably other "sdkapi" public types.

Should the opentelemetr-go be designed using generics?

[Aneurysm9]

This is something I've been wondering about myself. I think there is a very high hurdle to clear before we decide to take this path as our current policy is to support at least the current and immediately prior releases of Go, which would mean that we could not use features in 1.18 until after the release of 1.19 without changing that policy. That said, it may be worth making the change and I'd be interested in seeing what sort of improvements to the API could be offered by taking advantage of generics.

[MrAlias]

I definitely think it is an option worth exploring.

[MrAlias]

Go 1.18 is expected to be released in February 2022. With a 6 month cadence on these releases, that puts 1.19 being released around August 2022.

This means the question becomes: should we break our compatibility guarantee with the Go project to build our metric API with generics?

[MrAlias]

We also need to explore the feasibility of using generics in the API/SDK to motivate a decision here. This should involve building a prototype.

[jmacd]

I have been exploring the feasibility of using generics for the SDK in a branch here: https://github.com/open-telemetry/opentelemetry-go/compare/main...jmacd:jmacd/mapi3?expand=1

Since generics are very new, this will take developers a while to get used to. For myself, I am definitely appreciating generics to reduce the size and repetition inside the SDK.

For the API, the Go team has given a canonical example of using generics in a metrics API: https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#metrics

The OTel metrics API does not specify the kind of ordered-attribute interface favored inside Google, although we have discussed this as an optional support that a language could provide. I am not planning to pursue a generic API for OTel-Go, although if we want to take this topic up after GA, that's fine. (I know the Java and C++ APIs are probably going to want this.)

In the 1/13/22 OTel-Go SIG I plan to briefly share the branch linked above.

[MrAlias]

Follow on the consensus of the SIG:

• We want to make the API as usable and stable a possible. As mentioned in the release notes

  it is possible that there will be code using generics that will work with the 1.18 release but break in later releases

  For this reason, we do not want to utilize Go generic features in the API.

• The SDK is the primary place where generics can aid in design, as mentioned in the issue description. We would like to include their use there as we have more control over the life-cycle of the SDK.

I going to close this issue as this has been the consensus for a few weeks and is the approach we took with the API redesign and are taking with the SDK work.

[MrAlias]

Related to #2528