5 ms·

It'll be interesting to see how Go handles a new major version. Will it be a Python 3 situation? Or more like, I dunno, Ruby 2 and onwards.

by s_kilk 8y ago

kyrra 8y ago
With these proposals so far, nothing is breaking with existing code. Any code you right today that runs on Go 1.11, would compile and run with these proposals. They are just feature additions at this point (mainly some new keywords, like "contract", "handle", and "check").
SamWhited 8y ago
I don't know how Ruby 2 does things, but Go will definitely not be like Python 2/3. Old Go 1 programs will continue to compile under Go 2, but Go 2 programs will not compile under Go 1. It's also not certain that we will need a Go 2. It may be that all features can be written in a backwards compatible manner and the major version won't need to be bumped.
yashap 8y ago
I think the two big problems with the Python 3 rollout were a lack of compelling reasons to upgrade (at the time - many big features have been implemented in Python 2 in the years since), and upgrades like this being inherently scarier in dynamically types languages. If Go 2 brings improved error handling and generics, those are HUGE reasons for the community to get onboard and upgrade quickly. Plus with compiled languages, the upgrade is way less scary - so many errors will be caught at compile time that can sneak through as subtle bugs in dynamically types languages (unless there’s GREAT test coverage). Also, Go 2 may not even bring breaking changes! Though I’d imagine some things will still break no matter what (code analysis tools, programs that use variable names that become keywords, etc.). Maybe I’m being naive, but I think Go 2 will be adopted quickly with relatively little pain, as long as it brings super-desired features like genetics and error handling improvements.
- reggieband 8y ago
  > I think the two big problems with the Python 3 rollout When Python 3 was announced I thought "this is a great way to rollout". After a few years I thought "what a terrible rollout, even I haven't changed to version 3 100% yet because of some libraries I rely on are still only verion 2". Now I'm back on the positive side of things. It turns out, in the grand scheme of things, 5+ years for a new version to be adopted didn't really affect me in a negative way. I'm back on the "slow and steady wins the race" bandwagon.
  - nordsieck 8y ago
    There's a bit of survivorship bias there. There was a very real chance that Python would get replaced by another language in the same way that Ruby and Python replaced Perl. If that had happened, you'd probably still be in the "what a horrible rollout" frame of mind.
    - vgy7ujm 8y ago
      None of those really replaced Perl...
    - antod 8y ago
      I seem to remember that Ruby was already replacing Python pretty heavily 10 years ago. Rails was gaining momentum at a huge rate and Python web frameworks were dying, tools like Puppet were on the rise etc. The full history of Perl 6 still lay ahead too. If it hadn't have worked out in the end, it would be just as relevant to claim "what a horrible rollout" was just the benefit of hindsight talking. I think the Python devs and community need to take some credit for managing to pull off that transition successfully (even if it took longer than most expected). And to claw their way back into relevance again. And every other language community now has a case study they reference during discussions about language upgrades :)
- Jyaif 8y ago
  > upgrades like this being inherently scarier in dynamically types languages. So true.
bradfitz 8y ago
Is it an explicit design requirement that we never invalidate any Go 1 code or bifurcate the community. Any language changes must keep that in mind. Also, "Go 2" won't be a release as much as it'll be a series of releases. Go 2 might be called "Go 1.15.0". Even if it's named "Go 2.0.0" for marketing/excitement reasons, it'll still effectively be Go 1.15.0 and compile all Go 1 code and be able to call back (and forth!) between Go 1 and Go 2 seamlessly. We're not doing a Python 2/3 or Perl 5/6.
- zerocrates 8y ago
  Presumably that first "doing" in the last sentence was supposed to be a "not."
  - bradfitz 8y ago
    Whoops, thanks. Fixed.
    - psankar 8y ago
      Now you have two "doing" :)

It'll be interesting to see how Go handles a new major version. Will it be a Python 3 situation? Or more like, I dunno, Ruby 2 and onwards.

by s_kilk 8y ago

It'll be interesting to see how Go handles a new major version. Will it be a Python 3 situation? Or more like, I dunno, Ruby 2 and onwards.

kyrra 8y ago

With these proposals so far, nothing is breaking with existing code. Any code you right today that runs on Go 1.11, would compile and run with these proposals. They are just feature additions at this point (mainly some new keywords, like "contract", "handle", and "check").

SamWhited 8y ago

I don't know how Ruby 2 does things, but Go will definitely not be like Python 2/3. Old Go 1 programs will continue to compile under Go 2, but Go 2 programs will not compile under Go 1. It's also not certain that we will need a Go 2. It may be that all features can be written in a backwards compatible manner and the major version won't need to be bumped.

yashap 8y ago

I think the two big problems with the Python 3 rollout were a lack of compelling reasons to upgrade (at the time - many big features have been implemented in Python 2 in the years since), and upgrades like this being inherently scarier in dynamically types languages. If Go 2 brings improved error handling and generics, those are HUGE reasons for the community to get onboard and upgrade quickly. Plus with compiled languages, the upgrade is way less scary - so many errors will be caught at compile time that can sneak through as subtle bugs in dynamically types languages (unless there’s GREAT test coverage). Also, Go 2 may not even bring breaking changes! Though I’d imagine some things will still break no matter what (code analysis tools, programs that use variable names that become keywords, etc.). Maybe I’m being naive, but I think Go 2 will be adopted quickly with relatively little pain, as long as it brings super-desired features like genetics and error handling improvements.

reggieband 8y ago
> I think the two big problems with the Python 3 rollout When Python 3 was announced I thought "this is a great way to rollout". After a few years I thought "what a terrible rollout, even I haven't changed to version 3 100% yet because of some libraries I rely on are still only verion 2". Now I'm back on the positive side of things. It turns out, in the grand scheme of things, 5+ years for a new version to be adopted didn't really affect me in a negative way. I'm back on the "slow and steady wins the race" bandwagon.
- nordsieck 8y ago
  There's a bit of survivorship bias there. There was a very real chance that Python would get replaced by another language in the same way that Ruby and Python replaced Perl. If that had happened, you'd probably still be in the "what a horrible rollout" frame of mind.
  - vgy7ujm 8y ago
    None of those really replaced Perl...
  - antod 8y ago
    I seem to remember that Ruby was already replacing Python pretty heavily 10 years ago. Rails was gaining momentum at a huge rate and Python web frameworks were dying, tools like Puppet were on the rise etc. The full history of Perl 6 still lay ahead too. If it hadn't have worked out in the end, it would be just as relevant to claim "what a horrible rollout" was just the benefit of hindsight talking. I think the Python devs and community need to take some credit for managing to pull off that transition successfully (even if it took longer than most expected). And to claw their way back into relevance again. And every other language community now has a case study they reference during discussions about language upgrades :)
Jyaif 8y ago
> upgrades like this being inherently scarier in dynamically types languages. So true.

bradfitz 8y ago

Is it an explicit design requirement that we never invalidate any Go 1 code or bifurcate the community. Any language changes must keep that in mind. Also, "Go 2" won't be a release as much as it'll be a series of releases. Go 2 might be called "Go 1.15.0". Even if it's named "Go 2.0.0" for marketing/excitement reasons, it'll still effectively be Go 1.15.0 and compile all Go 1 code and be able to call back (and forth!) between Go 1 and Go 2 seamlessly. We're not doing a Python 2/3 or Perl 5/6.

zerocrates 8y ago
Presumably that first "doing" in the last sentence was supposed to be a "not."
- bradfitz 8y ago
  Whoops, thanks. Fixed.
  - psankar 8y ago
    Now you have two "doing" :)