Hacker News Reader

Comment by pjc50 | Hacker News Reader

Uhoh, they're still proposing to remove features. This is a terrible idea and crippled both the Perl and Python transitions. If you remove a feature and it doesn't compile existing programs, it's a new language. The automated backwards compatibility proposed might help, although it's not clear if you can mix files and libraries from different versions of the language?

View on HN

There's a distinct difference.

python3 code cannot import python2 libraries. That split the ecosystem.

Go intends for a go2 library to be able to import and use a go1 library.

This means there isn't a split in the ecosystem at any point in time.

It's fine to remove a feature as long as old programs still build because you must opt in to the removal via setting "version=go2" or whatever in go.mod.

This is distinctly different from being the perl and python transitions because the new compiler can still build old code, including with removed features, until you opt into the new language version.. and even once you do opt in, all your dependencies are fine whether they have opted in or not.

You can actually use Perl 5 and even Python code in Perl 6.

They do propose that, but with caveats. They mention removing string(i) in, say go 1.20. If a module notes that the maximum version of go that the module works with is 1.19 (because it uses that feature), then the 1.20 compiler can compile that module in go language 1.19 mode. Thus you can use 1.20 features in your module and still depend on the module that uses the deprecated syntax, because the go compiler can still operate on that old code.

This is different from python 3 because python 3 cannot run python 2 code, even if told that some library is python 2. That is where the migration pain came from.

I'm unconvinced by the max-version part, I can't see how it doesn't require either

A) being overly restrictive, and declaring the current released version as your max, breaking for a short time on each new lang version

B) being psychic, and knowing when (without the aid of semver) your package might break

An unmaintained package will not be updated with the max flag when the breakage occurs.

Any package always declaring the current version will have to be updated for every new release.

Both seem like a lot of admin.

I know using unmaintained packages isn't ideal in the first place, but it happens, and packages exist that are pretty much "finished" and very light on bugs, if they were stable and heavily exercised for some time before losing their maintainers.

The breakage you describe in A) shouldn't happen according to the proposal. The compiler for toolchain version X+1 should still be able to compile code that is language version X.

An unmaintained package doesn't need new features from then-future versions of Go, so it's fine if you declare the current version as your max. It doesn't break in the new version, it just doesn't have access to features introduced after the max version.

Won't you then lose out on performance improvements that don't break your code.

version of the language spec != version of the compiler

I.e. future compilers can understand previous version of the language spec.

As outlined in the proposal, you wouldn't miss out on performance improvements since it would still be the same underlying compiler and the version just controls the syntax rules. (And even if that were the case, it's not a very bad worst-case scenario for an abandoned project.)

What did Python remove?

Many things. The linked document notes that the print statement of Python 2 was removed from Python 3, harming migration.

The print statement to function didn't hurt migration. Nor did any of the other actual changes. What hurt the migration is a small but loud group of Python developers who think everything in the language was just fine, that not only was Python 3 unnecessary, it was actively bad and signaled a bunch of know-it-all theoretical type people from other languages coming in and taking over their own little corner of the wild west and imposing law and order where it wasn't asked for.

Actually, even those people aren't what hobbled the Python migration. What made it such a mess was that the core team didn't tell that crowd to fuck right off and get with the program or get left behind.

And even now with 2.7 nearing end of life, those same grumpy curmudgeons hang around web forums and reddit and blogs here and there, giving new people bad advice, complaining about how much better the old days were before unicode and async and types. I even saw someone griping about those new-fangled decorators and how monkeypatching was better.

The thing that made a mess out of the transition was the core team trying too hard to coax people who didn't want to move into coming along with them with a small bucket of carrots and no sticks. They tried to pull the bandaid off slowly and it took too long and still hurt like hell.

I couldn't agree more. There was a huge amount of wailing that, for instance, Python 3 suddenly made devs care about the difference between text and bytes, when Python 2 had let them happily write broken code without complaining.

Yes, you have to write correct code now. Yes, this requires changing some stuff. But yes, this is better for everyone in the (not so) long run.

The Python 3 transition has taken 10+ years and millions of developer-hours. It is perfectly reasonable to question whether the benefits have been worth the costs, especially when compared to other platforms like JavaScript that have made much greater advancements during that time.

See the release notes of Python 3.0:

https://docs.python.org/3.0/whatsnew/3.0.html#removed-syntax

The removals were actually an easier pill to swallow than the numerous subtle changes in behavior introduced by the big, deep switch to Unicode. I'm over it now, but that was painful!

This is my attempt to be sympathetic to the GP's point of view, perhaps they have a different example in mind.

One example comes from the new-style / old-style classes distinction and the method resolution order when considering multiple inheritance.

Python 2.3 introduced "new-style" classes which inherit from `object` and use the C3 resolution algorithm [1]. For backwards compatibility reasons, "old-style" classes without an explicit `object` base class still used the old method resolution semantics.

Python 3 does away with "old-style" classes entirely and all classes must use the "new-style" semantics.

There's presumably a ton of code that doesn't specify `object` as an explicit base class, and thus may have subtle broken behaviour under "new-style". Given Python 3's inability / unwillingness to simulate the old behaviour, I'm unaware of any tool that's able to rewrite Python 2 to 3 in a bullet proof fashion [2].

This is not the same kind of breakage that other people mention, like `print` being a function or `reduce` being moved to `functools`. Those are simply backwards incompatible "movements", not outright removals, and thus can be rewritten by automated tools.

[1] https://www.python.org/download/releases/2.3/mro/ [2] https://portingguide.readthedocs.io/en/latest/classes.html#n...

maybe not removed, but they certainly did make breaking changes to the language. here are some of the most obvious

python 2:

  print "foo"   # foo
  3 / 5         # 0
  apply         # <built-in function apply>

python 3:

  print "foo"  # SyntaxError: Missing parentheses in call to 'print'
  3 / 5        # 0.6
  apply        # NameError: name 'apply' is not defined

These are precisely the kind of changes one would make to a language if you wanted to cause as much pain as possible. (I say this as someone who has been paid to write a syntax-driven code rewriting tool to go from one language version to another.)

But at the same time, f-strings are soooo much better than the old way, or even .format().

For one, it removed the ability to do % formatting with bytes objects.

When working with a wire protocol like ssh, you need to work with sequences of bytes, not Unicode strings, and porting code that assembled them using % formatting was a huge pain; I tried and failed to port paramiko to python 3.

You might already be aware, but %-formatting with bytes is back as of 3.5.

Reply on news.ycombinator.com