Go is called Go, not Golang

[robpike]

Since the language is called Go, even though its domain is golang.org, it would be nice (and short) if the package identifier for Go modules was "go" rather than "golang".

[stevespringett]

IMO, 'golang' is more accurate as it differentiates the module system that's built into the go language vs third-party package managers for go such as dep and glide (among others).

One thing to consider is that PURL is already widely adopted in certain verticals. Changing it would inevitably break compatibility with commercial and open source tooling that already supports it.

Note to the rest of the admins: this is one of the reasons why #50 is so important.

[robpike]

I'm not sure about your first point. The go tool is called go, not golang: one writes 'go mod' not 'golang mod'. So golang vs. go has nothing to do with modules.

Regarding compatibility, until 1.0 happens is the time to get things right. Things can change until 1.0 is settled, and this is one thing I'd like to see changed.

I value your goals here in setting up a proper standard for a messy place.

[andrewstein]

@robpike The preference for "golang" seems to be intentional. See this commit: 8e2e367, but I do not have insight as to the reasoning

[robpike]

That commit does not provide an explanation but the comment above claims it is due to a mistaken belief that there is a different term for the module system than for the language.

[pombredanne]

@robpike I am honored that you (the creator of Go) drops by and cares about this little project!

The rationale for the switch from go to golang for types was that before we started using a pkg prefix and single scheme, the approach was instead of have as many schemes as types.

In that context, go was already an officially registered URL scheme @ IANA https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml and specified in RFC3368 https://tools.ietf.org/html/rfc3368 and even though not much used it was registered.

Therefore I decided then to use golang instead (and that happened in the early drafts).

Since we now have a single scheme pkg scheme, go would be a type and no longer a URL scheme so I am strongly inclined to defer to you. If anything it is shorter. And to conserve backward compatibility, we could support both (go and golang).

You also wrote:

Regarding compatibility, until 1.0 happens is the time to get things right. Things can change until 1.0 is settled, and this is one thing I'd like to see changed.

I have been resisting calling a version... but it looks like pressure is piling up!

@stevespringett you wrote:

IMO, 'golang' is more accurate as it differentiates the module system that's built into the go language vs third-party package managers for go such as dep and glide (among others).

One thing to consider is that PURL is already widely adopted in certain verticals. Changing it would inevitably break compatibility with commercial and open source tooling that already supports it.

I get your point but this is likely to be something that could occur again in the future, so what do you think about having aliases for types? (here go <-> golang) ?

Note to the rest of the admins: this is one of the reasons why #50 is so important.

I reckon that having a settled version may be best, but at the same time I have been resisting doing so so thing could settle into place nicely.

[pombredanne]

@ashcrow what's your take on this too?

[ashcrow]

Since we now have a single scheme pkg scheme, go would be a type and no longer a URL scheme so I am strongly inclined to defer to you. If anything it is shorter. And to conserve backward compatibility, we could support both (go and golang).

Switching to go and deprecate golang seems like a sane approach. Though I feel holding on to it for a version before dropping it completely to allow folks to switch is important. In other words, 1.0 would prefer go to golang but allow golang maybe with a warning, while 1.Y.0 drops golang.

Alias support might be nice, but I fear we'd be trying to future proof for something that shouldn't happen often.

[robpike]

@pombredanne Thank you for your careful consideration. The background is interesting.

[jkowalleck]

see also: #308 -- this proposes to deprecate golang for various reasons and publish a go definition that includes breaking changes.