* Angular.js - Don't want to be preaching - but it looks like version 2 will be die in the same way.

How does the generally successful ruby 1.8 to 1.9 transition fit in?

I think maybe is the answer it managed to barely do just as much backwards incompat as it could get away with. (Barely, it drove a lot of people crazy). But it was quite possible to write code that worked in both ruby 1.8 and 1.9, quite intentionally, despite the backwards incompatibilities.

Combined with a commitment from key players (esp Rails) to move to 1.9 and stop supporting 1.8, forcing the issue. And that it happened at a point when ruby/rails were at the peak of their popularity, not already on the downslide (Perl). Which of course effected how much backward incompat you can get away with.

That's the trick, predicting how much backwards incompat you can get away with, of course.

But of course, there's another lesson here too, which the OP astutely calls out in the "greenfield" section -- if you focus too much on stability and supporting existing projects, that's just another way to make the ecosystem go stale.

What can we learn from this? That we shouldn't attempt major changes that aren't backwards compatible?

Breaking backwards compatibility is a more apt description of that list than major rewrite.

Part of the lesson from Python 3 is that large numbers of people will only spend 3 years deciding whether a 5 year plan to make a major change to a 20 year old language succeeded or not.

Agreed. If there's one thing that Bill Gates understood better than everyone else (with the exception of maybe Intel) is that you never break backwards compatibility. You have instantly leveled the playing field for all of your competitors. Why should your users use YOUR new language if there are other languages that already exist and they are just as incompatible as your language?

It's not as simple as that. Eventually continued backwards compatibility hacks will cause non-negligible problems, and some of those same customers may start viewing the competition differently when they finally decide to rewrite or choose a new system to replace their aging one. It's a fine line.

> we shouldn't attempt major changes that aren't backwards compatible?

I think is more about practicality. Incompatible releases are a huge hassle for users; the payout should be equally huge to make it worth the effort of porting.

As the post says, a language should try to be the best choice for new projects: easier and more powerful than other choices, delivering better results with less effort. An incompatible release starts from a position where it requires more effort, so it must deliver much better results in much less time or it will be discarded on practical ground (and all the while having the same feel and strengths as previous releases - you can't make Go, call it Python 4 and expect people will love it). That's very difficult to deliver.

And compatibility was big reason why Windows 95 was a success.

I guess we should learn to design languages with extensibility in mind from the outset, so that later incompatible changes are much less likely to be necessary.

io.js has one major advantage over your other examples: it is tracking the same javascript that browsers are running.

When every major browser is moving in the same direction with a language, any server-side counterpart is best served moving in the same direction.

Without browsers, io.js would have likely ended up in the same place as all the examples above.

> The opposite: > * Node.js: it seems many consider the io.js fork based on up-to-date v8 js engine with ES6 support (nodejs 0.11/12 branch fork) and may leave the old nodejs 0.10.x behind

It seems too soon to tell what's going to happen with io.js. It was released just a few days ago.

You can add IPv6 to that list.

also opposite:

what is considered good c++ has changed pretty dramatically from what I learned in the 90s. Though afaik none of those changes were breaking.