Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Go is called Go, not Golang #67

Open
robpike opened this issue Oct 23, 2019 · 8 comments

Comments

@robpike
Copy link

@robpike robpike commented Oct 23, 2019

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

This comment has been minimized.

Copy link
Member

@stevespringett stevespringett commented Oct 24, 2019

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

This comment has been minimized.

Copy link
Author

@robpike robpike commented Oct 24, 2019

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

This comment has been minimized.

Copy link

@andrewstein andrewstein commented Nov 8, 2019

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

@robpike

This comment has been minimized.

Copy link
Author

@robpike robpike commented Nov 10, 2019

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

This comment has been minimized.

Copy link
Member

@pombredanne pombredanne commented Nov 25, 2019

@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

This comment has been minimized.

Copy link
Member

@pombredanne pombredanne commented Nov 25, 2019

@ashcrow what's your take on this too?

@ashcrow

This comment has been minimized.

Copy link
Contributor

@ashcrow ashcrow commented Nov 25, 2019

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

This comment has been minimized.

Copy link
Author

@robpike robpike commented Nov 25, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.