4 ms·

I'm a big fan of the assertion that a future Go 2 will never break Go 1 compatibility. I think if you need to make changes so significant to a language, you ma

I'm a big fan of the assertion that a future Go 2 will never break Go 1 compatibility. I think if you need to make changes so significant to a language, you may as well just fork and rename the language (an opinion I can see many holes in). I wonder: why not go further and say "there will never be a Go 2" in order to eliminate ambiguity about this? If a theoretical Go 2 will run all Go 1 programs, what would make it different from some Go 1.xx release? Some might interpret this post as saying that, but I don't think it quite does. It says "There will not be a Go 2 that breaks Go 1 programs."

sudhirj 3y ago
It becomes a semantic difference at that point. If Go is doing semver, and there are going to be no backward-incompatible changes, there's no reason to ever increment the major version. Everything is a minor version (compatible additions) and patch version (bug fixes).
jdc0589 3y ago
> I wonder: why not go further and say "there will never be a Go 2" Pretty sure they've said this in the past.
flakes 3y ago
The article does state that at the end: > The answer is never. Go 2, in the sense of breaking with the past and no longer compiling old programs, is never going to happen. Go 2 in the sense of being the major revision of Go 1 we started toward in 2017 has already happened.
cogman10 3y ago
Java went through this. There was a Java 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, and 1.7. Then, Java decided "You know what, we aren't breaking backwards compatibility so instead of naming things 1.x, let's just say Java 8, 9, 10...21" I think that ultimately makes sense.
- mrweasel 3y ago
  I did not know that was the reasoning or logic behind the Java 8, 9, 10 ... numbering, that clears up so many thing.
  - twic 3y ago
    Also relevant is that Sun had pulled the same trick with Solaris a few years earlier - Solaris 2.6 was followed by Solaris 7. Bigger version numbers make for better marketing. I am skeptical that backwards compatibility was strongly involved.
    - hbn 3y ago
      Apple also did a similar thing with OSX/macOS a few years ago - instead of making everything 10.XX they bump the major version (first number) every year now, continuing on from the 10 that the X represented, as if each version is the same increment as the jump from Mac OS 9 to Mac OS X (which was a jump to an entirely new codebase) Android did that too, much earlier starting with 5.0. Previously the major version was something of an indicator of a major visual/conceptual redesign. 3.0 was the tablet version, 4.0 was the move to the holo design language, 5.0 was material. Then they just kept bumping the major version every year since. I also assume it's just for marketing reasons.
      - chipotle_coyote 3y ago
        I’d argue that the “everything is 10.x” for Mac OS was also basically marketing. :)
- adrianmsmith 3y ago
  Ironically they then went ahead and made a massive change in Java 9 that, for the first time in Java's history, broke pretty much everything. Still angry about that...
  - szundi 3y ago
ainar-g 3y ago
> I wonder: why not go further and say "there will never be a Go 2" in order to eliminate ambiguity about this? They did, five years ago. Albeit with an “if”. https://github.com/golang/proposal/blob/d661ed19a203000b7c5441d2cd63a6e4b98ff2ba/design/28221-go2-transitions.md#go-2 https://github.com/golang/proposal/blob/d661ed19a203000b7c54... > If the above process works as planned, then in an important sense there never will be a Go 2. Or, to put it a different way, we will slowly transition to new language and library features. We could at any point during the transition decide that now we are Go 2, which might be good marketing. Or we could just skip it (there has never been a C 2.0, why have a Go 2.0?). > Popular languages like C, C++, and Java never have a version 2. In effect, they are always at version 1.N, although they use different names for that state. I believe that we should emulate them. In truth, a Go 2 in the full sense of the word, in the sense of an incompatible new version of the language or core libraries, would not be a good option for our users. A real Go 2 would, perhaps unsurprisingly, be harmful.
- Thedarkb 3y ago
  C had a breaking change this year, pre-ANSI C programs need to have all of their function definitions changed for them to be compatible with C23.
- tmpz22 3y ago
  > We could at any point during the transition decide that now we are Go 2, which might be good marketing. Among the (entirely?) dev-oriented consumers of Golang would the shininess of "2.0" really outweigh the "ugh documentation is going to get harder to find" and "ugh I now need to increase my auditing of dependencies" and other similar fatigue? Is Google universally good at marketing?
- deleted 3y ago
  [deleted]
- ilyt 3y ago
  But Java absolutely had versions that broke old code
- pjmlp 3y ago
dcow 3y ago
You might be overestimating the type of change required to break source compatibility. A benign example is adding a keyword. Let's say you want to add a new language feature and the community unarguably wants the feature and the right or only way to add it is with a new keyword. If you're not allowed to break source, then you can never add the feature. I understand your argument for big things like changing the semantics of the language. But a backwards-incompatible change can also be rather benign.
- rsc 3y ago
  It's not true that Go can't add new keywords. Now that we have Go modules, all Go code is now explicitly annotated with the version of Go it was written against. We can add a new keyword in a later version of Go as long as the compiler can still also compile code written for the older versions of Go. (The go command tells the compiler which version of Go to use for each package it compiles.) What we're not going to do is abandon all the code written for older versions of Go, like Python 3 or Perl 6 did. Python is recovering now but it easily lost a decade to the Python 2 -> Python 3 transition, almost certainly unnecessarily. And Perl lost even more.
  - jen20 3y ago
    This is a the TL;DR I wish was the first paragraph of the article! Could this mechanism be used to patch up unfortunate evolutions in the standard library also? For example, all of the `WithContext` functions that could be folded into the (more common?) non-contextful versions?
- crickey 3y ago
  I dont undestand your example, plenty of languages add new keywords without breaking backwards compatibility, its removing a keyword that would cause such and issue.
  - meepmorp 3y ago
    I have named a function 'foo', in current version of language. A future change makes 'foo' a keyword. My code was broken by adding a keyword.
015a 3y ago
I'm not sure that's a relevant distinction. If you take the stance that a major version has to mean breaking API compatibility with the previous major version, semver style, then their statement is equivalent to saying "there will never be a go2". If you don't take that stance, then their statement leaves open the possibility that, fifty years from now, we'll be at go1.102 and someone will say "hey, these numbers are getting pretty big, maybe we should just call this next release go2"; and that's fine. That's literally and exactly what Linux does; when the number gets big, it becomes easier to type smaller first number, so rename version to smaller first number. Its not semver, but semver doesn't have a monopoly on how software must be versioned, and leaving room in the language today to do that is totally cool.
afavour 3y ago
I’d argue Rust’s editions are a good counter argument to that. The differences between editions really aren’t huge despite being breaking changes. In theory I like the idea of backwards compatibility never changing but in reality some breaking changes really do make sense and being permanently on the hook for a language feature that didn’t take X or Y into account when it was created doesn’t feel like a win.

sudhirj 3y ago

It becomes a semantic difference at that point. If Go is doing semver, and there are going to be no backward-incompatible changes, there's no reason to ever increment the major version. Everything is a minor version (compatible additions) and patch version (bug fixes).

jdc0589 3y ago

> I wonder: why not go further and say "there will never be a Go 2" Pretty sure they've said this in the past.

flakes 3y ago

The article does state that at the end: > The answer is never. Go 2, in the sense of breaking with the past and no longer compiling old programs, is never going to happen. Go 2 in the sense of being the major revision of Go 1 we started toward in 2017 has already happened.

cogman10 3y ago

Java went through this. There was a Java 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, and 1.7. Then, Java decided "You know what, we aren't breaking backwards compatibility so instead of naming things 1.x, let's just say Java 8, 9, 10...21" I think that ultimately makes sense.

mrweasel 3y ago
I did not know that was the reasoning or logic behind the Java 8, 9, 10 ... numbering, that clears up so many thing.
- twic 3y ago
  Also relevant is that Sun had pulled the same trick with Solaris a few years earlier - Solaris 2.6 was followed by Solaris 7. Bigger version numbers make for better marketing. I am skeptical that backwards compatibility was strongly involved.
  - hbn 3y ago
    Apple also did a similar thing with OSX/macOS a few years ago - instead of making everything 10.XX they bump the major version (first number) every year now, continuing on from the 10 that the X represented, as if each version is the same increment as the jump from Mac OS 9 to Mac OS X (which was a jump to an entirely new codebase) Android did that too, much earlier starting with 5.0. Previously the major version was something of an indicator of a major visual/conceptual redesign. 3.0 was the tablet version, 4.0 was the move to the holo design language, 5.0 was material. Then they just kept bumping the major version every year since. I also assume it's just for marketing reasons.
    - chipotle_coyote 3y ago
      I’d argue that the “everything is 10.x” for Mac OS was also basically marketing. :)
adrianmsmith 3y ago
Ironically they then went ahead and made a massive change in Java 9 that, for the first time in Java's history, broke pretty much everything. Still angry about that...
- szundi 3y ago

ainar-g 3y ago

> I wonder: why not go further and say "there will never be a Go 2" in order to eliminate ambiguity about this? They did, five years ago. Albeit with an “if”. https://github.com/golang/proposal/blob/d661ed19a203000b7c5441d2cd63a6e4b98ff2ba/design/28221-go2-transitions.md#go-2 https://github.com/golang/proposal/blob/d661ed19a203000b7c54... > If the above process works as planned, then in an important sense there never will be a Go 2. Or, to put it a different way, we will slowly transition to new language and library features. We could at any point during the transition decide that now we are Go 2, which might be good marketing. Or we could just skip it (there has never been a C 2.0, why have a Go 2.0?). > Popular languages like C, C++, and Java never have a version 2. In effect, they are always at version 1.N, although they use different names for that state. I believe that we should emulate them. In truth, a Go 2 in the full sense of the word, in the sense of an incompatible new version of the language or core libraries, would not be a good option for our users. A real Go 2 would, perhaps unsurprisingly, be harmful.

Thedarkb 3y ago
C had a breaking change this year, pre-ANSI C programs need to have all of their function definitions changed for them to be compatible with C23.
tmpz22 3y ago
> We could at any point during the transition decide that now we are Go 2, which might be good marketing. Among the (entirely?) dev-oriented consumers of Golang would the shininess of "2.0" really outweigh the "ugh documentation is going to get harder to find" and "ugh I now need to increase my auditing of dependencies" and other similar fatigue? Is Google universally good at marketing?
deleted 3y ago
[deleted]
ilyt 3y ago
But Java absolutely had versions that broke old code
pjmlp 3y ago

dcow 3y ago

You might be overestimating the type of change required to break source compatibility. A benign example is adding a keyword. Let's say you want to add a new language feature and the community unarguably wants the feature and the right or only way to add it is with a new keyword. If you're not allowed to break source, then you can never add the feature. I understand your argument for big things like changing the semantics of the language. But a backwards-incompatible change can also be rather benign.

rsc 3y ago
It's not true that Go can't add new keywords. Now that we have Go modules, all Go code is now explicitly annotated with the version of Go it was written against. We can add a new keyword in a later version of Go as long as the compiler can still also compile code written for the older versions of Go. (The go command tells the compiler which version of Go to use for each package it compiles.) What we're not going to do is abandon all the code written for older versions of Go, like Python 3 or Perl 6 did. Python is recovering now but it easily lost a decade to the Python 2 -> Python 3 transition, almost certainly unnecessarily. And Perl lost even more.
- jen20 3y ago
  This is a the TL;DR I wish was the first paragraph of the article! Could this mechanism be used to patch up unfortunate evolutions in the standard library also? For example, all of the `WithContext` functions that could be folded into the (more common?) non-contextful versions?
crickey 3y ago
I dont undestand your example, plenty of languages add new keywords without breaking backwards compatibility, its removing a keyword that would cause such and issue.
- meepmorp 3y ago
  I have named a function 'foo', in current version of language. A future change makes 'foo' a keyword. My code was broken by adding a keyword.

015a 3y ago

I'm not sure that's a relevant distinction. If you take the stance that a major version has to mean breaking API compatibility with the previous major version, semver style, then their statement is equivalent to saying "there will never be a go2". If you don't take that stance, then their statement leaves open the possibility that, fifty years from now, we'll be at go1.102 and someone will say "hey, these numbers are getting pretty big, maybe we should just call this next release go2"; and that's fine. That's literally and exactly what Linux does; when the number gets big, it becomes easier to type smaller first number, so rename version to smaller first number. Its not semver, but semver doesn't have a monopoly on how software must be versioned, and leaving room in the language today to do that is totally cool.

afavour 3y ago

I’d argue Rust’s editions are a good counter argument to that. The differences between editions really aren’t huge despite being breaking changes. In theory I like the idea of backwards compatibility never changing but in reality some breaking changes really do make sense and being permanently on the hook for a language feature that didn’t take X or Y into account when it was created doesn’t feel like a win.