Serious question: what are the odds that go 2 ends up like python 3 and it takes the world over a decade of pain to migrate? (I like both python and go, and I’m still maintaining a sizable body of py2 code.)
“Backwards compatibility forever” seems like unnecessary shackles, and the language should be able to grow — I’ve seen some nice proposals for improvements. I just wonder what the strategy is going to be for migrating code from go1 to go2 and how painful that’s going to be.
Not a Go développer here, but let’s take the example of Java when it got (for example) generics or functional features.
There was NO going back.
These were so fundamental improvements that the past was absolutely outdated as soon as those new features were available.
May be the same thing will happen for Go
While I agree with what you're saying, that's not the GP's point. They're talking about backwards compatibility, i.e. old code running on new versions. Java has been extraordinarilly good at that (maybe too much so), with the possible exception of Java 9. Try running Java 1.0 code on JDK 17 and it'll probably run fine. Try running Python 2 code on Python 3 and you're generally going to be in for a very rocky ride.
Technically yes.
But, to me, the question is how developpers are changed by a given paradigm shift.
It happened with generics, it happens with functional programming. So an evolution in the language can just make its past versions instantly outdated.
[afaiu, python 3 did not do that. But my point is to say that it can happen.]
The issue of Python 2 / Python 3 is that the two were not compatible, which made the transition extremely complicated. That has nothing to do with the new version making the old one essentially outdated because of the usefulness of its contents.
The Go maintainers already said that they don't have any plans to do an actual version 2.0 anymore. Generics turned out to be possible without breaking backward-compatibility.
IMHO the long python3 migration was well executed and we're now comfortably on the back side of it. Reminds me of perl4=>5 and other big lifts.
Yes, commercial codebases understaffed for maintenance are kinda stuck, just like any legacy system. IMHO the solution must come from the business model down. Also, security, compliance & cost can help drive priority.
I’ve never heard that take, it seemed completely botched to me. The first couple versions of py3 didn’t even work well, and they were still pushing people to cut over
It wasn't well executed. The standard migration tool (2to3) was kind of considered a failure and the better one (six) wasn't ready, or even around at the time.
Python came this || close to dying during the migration, its users all having moved to other languages. Primarily data science saved it and then some time passed and libraries moved on, etc, and after a while the cost benefit calculation started swaying towards Python3, probably after 3.3 at least, so 4 years after Python3's launch.
This is an absolutely implausible take. Perl 4's entire lifetime was about 5 years; released in 1991 and Perl 5 utterly dominant by 1996. Python 2 shows no signs of an actual EOL to this day!
Go-1 and Go-2 code could even cohabit using something similar to Rust’s editions system e.g. the `range` behaviour could be something like a package opt-in.
And half the article could be fixed by adding new APIs and deprecating the old ones.
Languages like Rust have solved this through the concept of editions (or whatever you want to call it), essentially package or module-level “compilation mode” which allows evolving the language without breaking the old code.
The issue of the Python transition is that it was way too massive and the repercussion were way too widespread (e.g. they necessarily leaked into the APIs) for this to be possible, despite Python having an entire mechanism to handle this with `from __future__` (though admittedly that being a file-level attribute makes it less than ideal to move the language forwards).
If you can make compiler work with both - new and old code, then yes, I totally agree. But Python expected you to transpile your code to new version and recompile while also updating many of your dependencies. And that’s not something you easily can do in large codebases.
I’m not sure how editions in rust work, but if compiler can compile all editions and link them in single binary, then its something I’m totally for. But if someone expects people to go through millions of lines of old code and make sure it all works fine after migration to new version of lang, then I’m not sure your language can succeed.
> If you can make compiler work with both - new and old code, then yes, I totally agree.
Which you can, technically even Python has that mechanism (`from __future__ import <thing>` can change the language syntax).
However the ability to use that for the 2/3 transition was basically nil as an enormous number of apis were impacted, the syntax changes were really the easy bits, the semantics were much more difficult to deal with (talking from experience).
> I’m not sure how editions in rust work, but if compiler can compile all editions and link them in single binary, then its something I’m totally for.
“Backwards compatibility forever” seems like unnecessary shackles, and the language should be able to grow — I’ve seen some nice proposals for improvements. I just wonder what the strategy is going to be for migrating code from go1 to go2 and how painful that’s going to be.