Hacker News Reader

Comment by s_kilk | Hacker News Reader

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.

View on HN

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.

Presumably that first "doing" in the last sentence was supposed to be a "not."

Whoops, thanks. Fixed.

Now you have two "doing" :)

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.

> 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.

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.

None of those really replaced Perl...

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 :)

> upgrades like this being inherently scarier in dynamically types languages.

So true.

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.

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").

Reply on news.ycombinator.com