Anecdotal evidence from the Pythonistas I've known in my career -- they stick to it because they like it, it's old (to them that means it's a proven tech) and because there's too much intertia in their organization to move on to something else.

Technologies aren't only popular because of their quality, or shall we bring PHP once again to prove this point?

Yup, this is what I hate about all of the we-must-be-right-look-at-our-adoption-rate arguments. From the blog post:

> There is a reason Go programmers choose to program in Go, and I believe that reason stems from our core tenets of simplicity and readability

Not the reason I choose it, I choose it for tight cross platform binaries and nice stdlib. Arguments made against generics should be technical, not political... complexity may be subjective, but the justification for the definition can still be technical.

As I mentioned in my more lengthy comment right here -- https://news.ycombinator.com/item?id=14563597 -- popularity is very loosely correlated to the quality of the popular thing. There's ease to pick up, there are pressing business needs fixed by a creative junior Python dev, there's the businessmen loving quick solutions (and future be damned of course), there's inertia, there's skepticism ("but our current system is working! why switch?"), there are tens of other such phenomena that can be attributed to the very buggy automatic brain processes.

So yeah, I hate the we-must-be-right-look-at-our-adoption-rate arguments as well. :)

Anecdotally, it seems to me that it's increasingly common to see Python as the language of choice in greenfield projects. I've seen this in organizations -- scientific, academic, industrial -- that aren't primarily software-oriented. This involves both internal applications/utilities and general use for statistical analysis, machine learning, and data processing.

It may be that choosing Python for a customer-facing web service would only be done now because of inertia or risk aversion, but there's tons of new users who don't care about the GIL and who like Python for its pleasant language design, good libraries, and ease of interfacing with C.

PHP got popular because it was easy to use, and then because of inertia and path dependence. I don't think anyone was really happy to "grow with" PHP, in terms of gaining in expertise and creating increasingly complex code. I don't see this problem with Python -- leaving aside issues with concurrency, the language largely doesn't get in the way of writing quality code.

Yes and no.

(1) People are always inclined to one or the other language, even the non-technical people. I am sure most of the HN audience knows businessmen who read 3-4 short articles and felt like tech experts. Or a junior dev friend of theirs told them "man, language X is awesome". And it picks up from there.

(2) Python is a pretty good language, there's no arguing that. And if you have a team where even not-very-technical people can code an easy script with it, there's a subconscious peer-pressure to choose it for your next greenfield project. It's easy to pick up even if you're new to programming. That's a plus per se, but us the Homo Sapiens always prefer instant gratification over sensible long-term investments. It's our nature. That's why I picked Ruby -- after running away screaming from the Java EE world -- seven years ago. (Now I regret that decision, by the way.)

(3) Many projects don't care about concurrency. Languages with GIL who are easy to pick up -- Python and JS being the prominent examples -- are bound to be popular. You're correct on that point, 101%.

(4) Python has good C-bindings with awesome libraries. Facts are facts.

(5) I've known people who ran away from Python. I am not making this an argument against the language itself, I am just giving you perspective on your statement that "one can grow with Python". Yes they can, some choose not to. That's not an argument in either direction -- not for, and not against the language. It's a natural phenomena with humans.

---

I'm seeing popularity in general only loosely bound to quality. Many actors, software technologies, hardware pieces, TV shows etc. etc. became popular because there was a pressing need for something in the area and that entity arrived in time to satisfy the need. From then on the human nature of being creatures of habit kicks in and much better alternatives go unnoticed for years (or decades) and the old stuff gets replaced only when it becomes blatantly obvious that it's inadequate, many times in a row.

It seems our human systems hate gradual and constructive change. It always has to be semi-cataclysmic changes.

I digressed. Please note that I am in partial agreement with you, but felt compelled to give another take of your points.

If my experience with c# is anything to go by, you can't "just" add async either. The details of how it works are very complex, the syntax requires a lot of noise words all over the code, and there are many ways to get it wrong.

That's just a cost of retrofitting a paradigm-changing feature.

I would say, based on some experience with async capabilities in Python, Java, Go, and C#, that C#'s async/TPL implementation is among the more elegant. Its internals may be complex and it is not without some caveats that must be understood, but I find that it introduces the least amount of extraneous keywords and code constructs in the business logic of an application. And unlike some languages such as Java, C#'s async capabilities are well-supported throughout its core libraries. As someone who builds a lot of data processing applications in Java that benefit from both high concurrency and non-blocking IO, I find myself wishing Java's async capabilities were more like C#'s.

The author was specifically talking about concurrency. You just repeated his point.