Change golang namespace to 'go', rather than 'gc'

[djaglowski]

Resolves opentelemetry-go-contrib #350.

This was discussed briefly in the Golang SIG in December. Consensus at the time was that go is clearer than gc and sufficiently appropriate. The move away from gc is helpful in part because the namespace is used to mean "garbage collector" elsewhere in the semantic conventions.

Related issues #

opentelemetry-go-contrib #1456

[bogdandrutu]

:) it has a GC :))

[djaglowski]

As noted in my response to Tigran's question, I've learned that Go has a runtime.Compiler constant that is either gc or gccgo. This weakens my proposal somewhat, but I still suggest that OTel use go instead of gc in order that the namespace is recognizable to those who are not familiar with this constant in Go's runtime package.

I've also added exact guidelines for populating process.runtime.name, process.runtime.version, and process.runtime.description.

[djaglowski]

cc: @open-telemetry/go-approvers

[XSAM]

LGTM

[pellared]

I cannot unresolve a comment 😄 Please just take a look at: #2262 (comment) (it is not a blocker for me)

[SergeyKanzhelev]

Thank you! Let's leave this PR hanging for couple of days to give chance other @open-telemetry/proto-go-approvers to comment

[tigrannajaryan]

@open-telemetry/go-approvers @open-telemetry/go-maintainers please review.

[Aneurysm9]

I do not believe this change is necessary. This affects a value in an attribute that clearly does not relate to garbage collection. For attribute keys created by our runtime metrics instrumentation we already use runtime.go.*. Having a special case for a particular compiler does not make sense to me here.

[djaglowski]

The initial intent of this PR was to support the process.runtime.go namespace, but this was based on a misinterpretation of the current scope of this file.

The process.runtime namespace is established earlier in the file, so I was looking at the Go Runtimes section as establishing process.runtime.gc and process.runtime.gccgo namespaces, under the guidelines described here.

## Process runtimes

**type:** `process.runtime`

...

### Go Runtimes

| Value | Description |
| --- | --- |
| `gc` | Go compiler |
| `gccgo` | GCC Go frontend |

Only after feedback did I take concern of the attribute values, and yet until now I did not recognize that my initial assumption about namespaces was wrong. Anyways, I see now that process.runtime.{environment} namespaces are not defined here. Obviously this changes the character of the PR for me, and for anyone I may have misled.

---

I do not believe this change is necessary. This affects a value in an attribute that clearly does not relate to garbage collection. For attribute keys created by our runtime metrics instrumentation we already use runtime.go.*. Having a special case for a particular compiler does not make sense to me here.

I assume we still want to specify exactly how process.runtime.name and process.runtime.version should be obtained in Go and that at question is only whether we should change the value gc to go.

I think there is a case for renaming it go if there is a chance that Go runtimes will eventually be differentiated into separate namespaces. i.e. If we're eventually going to end up with process.runtime.go.* and process.runtime.gccgo.*, then we should probably align this value to those namespaces. Any thoughts on whether this is an eventuality?

[Aneurysm9]

I think there is a case for renaming it go if there is a chance that Go runtimes will eventually be differentiated into separate namespaces. i.e. If we're eventually going to end up with process.runtime.go.* and process.runtime.gccgo.*, then we should probably align this value to those namespaces. Any thoughts on whether this is an eventuality?

That actually seems like a reason for not renaming it. If we made such a change users could know that any metric bearing runtime.go.* names did not distinguish them by compiler and that any with runtime.gc.* or runtime.gccgo.* did. If we wanted to rename anything in that case I'd maybe see using runtime.go-gc.*` or similar.

That said, I think it is all irrelevant as the process.runtime.name resource attribute should identify the runtime used and that attribute of any metric with a runtime.go.* name should be consulted to determine the particular runtime used. I think we should avoid putting too much responsibility on metric names when we have attributes to enrich their meaning in well-defined ways.

[MikeGoldsmith]

Thank you! Let's leave this PR hanging for couple of days to give chance other @open-telemetry/proto-go-approvers to comment

I'm happy for this change to go ahead too 👍🏻

[jmacd]

Yes, "gc" is plan9-ism that probably few people in this community actually care about.

[SergeyKanzhelev]

@Aneurysm9 how strong is your position? Please indicate if your comment "That actually seems like a reason for not renaming it." is blocking so we can try to find a consensus.

[Aneurysm9]

If there is consensus that go is more appropriate than gc and I am the only opposing voice, then I will not stand in the way of the change. I would prefer gc as it seems to me to be more correct and is certainly simpler to implement, requiring no change to our current implementations. I also worry about setting a precedent for second-guessing the results of the runtime.Compiler value rather than trusting that the compiler authors know how to identify the thing they are creating.

Again, not going to block if I'm the only one that feels that way, but I would like for those that approved prior to the comment @djaglowski made about misinterpreting the purpose of this file to re-assess their approvals. It seems that the PR was created for one purpose, realized to not be appropriate for that purpose, but maintained anyway. We should assure that it is being approved for the currently intended purpose.

[jmacd]

@Aneurysm9 if the variable in question were named process.runtime.compiler then I'd agree we should not translate "gc" into "go". The semantic convention is named process.runtime.name and it feels like an appropriate definition for Go: Use the value of runtime.Compiler as the runtime name except for its cryptic value "gc" which indicates the standard runtime, in which case use "go".

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.