> How do you define just fine? It's taken us many years to migrate EMCA versions only to have multiple incompatible runtimes.

ECMAScript versions are forward-compatible. Any valid ECMAScript 3 code is also valid 5.1, 2015, 2016, etc.

I'm not sure what migration you're talking about. If you mean using new language features before your runtime targets support them, that's kinda on you. Even so, the ecosystem has tons of robust solutions for supporting legacy interpreters. Most notably, Babel does a wonderful job of transpiling to lower language-version targets.

>How do you define just fine?

Besides the total domination of the web programming space, which is of course aided by it being the only option:

1) Used by choice even on the server and application development (where it was never the only option, and wasn't even preferable/viable before)

2) Fast pace of language development

3) A thriving package ecosystem with millions of packages

4) Adopted by all major companies

5) Three best of class runtimes (v8, JavascriptCore, Tracemonkey (?)) by 3 major vendors, with performance that smokes any dynamic language that is not LuaJit

6) Increasingly adopted as an embedded scripting language in all kind of apps

7) With a viable gateway into both a native trans-language runtime (webassembly) and a typed version of the language (typescript).

>How are them generics?

They're doing great. It's not that type erasure is that big of a deal, and Java might even get it with Valhalla eventually anyway. It's not a "backwards compatibility prevents this" issue (which is our topic here), it's a "no time devoted to add it in yet" issue.

Now do C#.

You are moving the goalposts and ignoring the fact that Python3 still didn't deliver anything for most users.

>Of course it's a "cargo cult" when someone disagrees with you.

No, it's obviously "backwards thinking", right?

>* "Just fine"... that explains why so many shops are dropping support for straight Javascript and switching to TypeScript or CoffeeScript before that.*

CoffeeScript was just adopted (and not that much in the first place) because it brought new syntax/features earlier. Now JS has been getting new syntax itself at a great pace and CoffeeScript just died off.

As for TypeScript, this is just Javascript + type annotations. Kinda like what Python is getting with 3.6 and mypy, but more useful and with actual tooling available. So not sure how "TypeScript or CoffeeScript" prove anything about JS not doing great.

>Likewise, Java development is slowly being superseded by Kotlin. Java is a mess, there are often 3-4 ways to do simple things and many of them are just terrible for performance.

Python has 10x+ worse performance, and more than 3-4 ways to do simple things (from package management to basic libs), most of which are just terrible for performance.

Compared to that, nobody has had any problem with Java performance for 15+ years...

And Kotlin is still insignificant except in the Android space where it's pushed, so there's that. Java sees an order of magnitude more usage.

> But the incompatibility between Python 2 and Python 3 is perhap s only a symptom of a larger problem. The Python developers have decided that backwards compatibility is not that important any more.

Exactly: and that was a wrong decision for anybody but the developers of Python.

Everybody else prefers having something that works: "The improvements are welcome, but please allow us to to run our old programs too, thank you, and allow us to use that new feature only once we need it."

It's an obvious expectation. We would also hate a new version of a word processor which wouldn't open our old documents. Or a new version of Photoshop which wouldn't open our old pictures. Or a new version of the browser where only the newest web pages are visible.

It follows that it was absolutely technically possible to have a new version of Python in which the old programs still work. It's the failure of the developers that they haven't made it.

Compare that decision of theirs with the policy of Linus Torvalds who insists that the old user programs should never break on newer kernels.

> It is, however, a huge problem for domains like scientific computing, where most code has no maintainers and even for very important code there is no budget or staff for maintenance

I think that's a tool selection problem, not just confined to the python world. If the language and libraries won't have a supported lifespan that matches with the maintenance budget of the projects using them then the wrong tool was chosen. If a project is expected to have a 10+ year lifespan of little to no maintenance then it needs to be built on languages/libraries that will have supported versions for that long.

> It is, however, a huge problem for domains like scientific computing, where most code has no maintainers and even for very important code there is no budget or staff for maintenance:

Data science is doing just fine, in fact is leading the migration: https://www.jetbrains.com/research/python-developers-survey-...

Discussion of Hinsen's post on HN:

https://news.ycombinator.com/item?id=17058269

And yet, somehow, Python manages to be a bigger mess than than both of them combined.

Java is nothing like a mess, and JS is going from strength to strength.

> Almost everyone hates both Java and Javascript.

I just don't think that's true.

And I dislike Python, but that's at best a cool story, bro.

This is a story about language upgrades. Those languages showed how to do it right.

Javascript is a hugely popular language, as is Java.

Some hipsters hate "Java and Javascript". The world at large loves them.

At some point plain users hated Java applets and Java desktop apps, but those are not a thing much more. In the server space, very few that use it hate Java, and millions use it.

Ah yes, let's turn this into a good old "your language sucks" thread

> JS and Java can do that because they were designed reasonably well from the start.

Javascript was knocked up over a week or so. Sure it implements concepts from Scheme and other languages but it was certainly not "designed reasonably well from the start". Otherwise we wouldn't have needed books such as Crockford's "Javascript The Good Parts" to help us understand areas of the language to avoid/misuse.

> Python's language was not solid (e.g., strings not unicode by default)

From the article:

"Python itself predates the first volume of the Unicode standard which came out in October 1991."

Kind of an odd slam, given that Python (and most other widely used languages) predated Unicode.

In any case, I think the jury is still out on whether Unicode in the primary string type is a good idea.

It's funny that you should bring up Unicode strings as an example. Java strings aren't Unicode by modern standards - their char is fixed as 16 bits, because back in the day, UCS2 was "good enough for everybody". So the moment you have, say, an emoji, stuff like length() and indexing is no longer dealing in actual codepoints. And you can slice in the middle of a surrogate pair, and end up with an instance of String that's not even valid UTF-16.

Python didn't get Unicode until later, so it had a chance to do it right - and it finally did, even on platforms like Windows where wchar_t is also 16-bit for historical reasons.

I wouldn't call Js a reasonably well designed language but at least it supports Unicode strings.

> That's only true if you ignore all packages on PyPi.

Presumably any packages worth maintaining will have far more dependent projects, so it's still far less overall effort.

> It's extremely hard to keep compatibility with Python 2

So don't? I don't think most of the people dragging their feet on the upgrade need or even want new features. A stable python 2 branch with bug fixes and security patches would suffice for most and be ideal for many. Over time the bug fixes should trend to zero and there probably aren't a heap of security issues in python projects anyway.