3 ms·
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 f
by lolive 5y ago
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
- masklinn 5y agoNot sure how relevant that is, the old code worked fine in post-generics Java.
- lolive 5y agoTechnically 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.]
- masklinn 5y agoBut that’s a completely different matter. 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.
- lolive 5y agoOk. My bad.
- chris_overseas 5y agoWhile 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.