> 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.

And yet Python is eating the world: http://pypl.github.io/PYPL.html

Not that I'm implying that 'popularity' is a good measure of anything.

Javascript is the king of compromises. It's supported by every browser on the planet so of course support is massive. It's not as if a front end web developer can choose to work on the web and not use Javascript in some form or another.

Python is popular largely based on the fact that it's so approachable. It is the BASIC/ VB of modern times for whatever that is worth. It does scale up to larger projects and is frequently used for big scale stuff, but I suspect the fact that it's so ubiquitous has more to do with the fact that it's also easy to pick up and for companies to find people with Python dev skills (or train them up).

Then what are you implying?

Perhaps that listing all the excellent reasons for why some tech is 'better' than another does not translate into said tech being used.

Now do C#.

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

This is a hugely American point of view. For anyone who has to deal with unicode on a regular basis, the better unicode support alone is a huge improvement. That's without even looking at the advantages of Async support which offers big performance benefits for web developers—roughly 70% of Python users.

Fair criticism. But shouldn't you be even more pissed that the Unicode release was botched and we're still talking about it more than 10 years after?

When I upgrade to a new version of C# ... nothing happens.

Backwards compatibility is what made Microsoft the company it is. I think Python deserves all the crap it gets for 2 vs 3.

They have to be backwards-compatible to persuade people to pay for their proprietary products rather than switch to another vendor.

So you're saying backwards-compatibility is awesome. I agree.

Note that the question is not "Shall we support Unicode?". Clearly we should.

The question is rather whether it would have been better to gradually improve support for it in a Python2-esque way, rather than creating a discontinuity and a raft of new problems, some of which linger to this day.

Also, for many purposes, there is wide agreement that ASCII is still the way to go. Even if Americans vanished tomorrow, the majority of remaining programmers in the world would prefer to look at source code in English, which they already know, rather than a host of other languages, most of which they don't.

There was no way to gradually improve Unicode support in Python without breaking things, because a big part of it was stuff like implicit str/unicode conversions - that were broken because they practically never use the right encoding, but that you can't remove without introducing as much breakage as Python 3 did.

You lack imagination here :) There are several solutions that could have been pursued, including introducing a completely new type and effectively duplicating the existing string library for it.

It's not just the string library that is affected. It's literally every API in the stdlib that returns a string. You'd have to fork all of those, because changing any of them to return a completely new type would be a breaking change as well.

Unicode support isn't about supporting unicode in files of source code!

They did try to do it in Python 2 and intruded Unicode type. The problem was that not only it didn't help, it is the main reason why migration to Python 3 is so painful.

You are replying out of context here. The comment I was replying to was specifically "Python3 still didn't deliver anything for most users". Which is just not true.

Replying here because the other is nested too deep.

You do realize that C# was itself Microsoft's replacement for C++ right? And that when C# was released it had it's own growing pains and long roll-out in spite of having the worlds biggest corporation pushing it.

Python as a language is far older than C# so it had a lot more baggage than C# does.