Go is new and has lots of issues. It's annoying on many fronts and badly needs improvements in packaging area. It's good for some things and worse for others.

JS is for frontend, because it's the only supported language. (although there are python-to-js compilers available if you really want to use it)

Julia for data science? Only if you started recently. R, numpy/scipy, mathematica, matlab, etc. still rule data science.

The projects you listed for python are fairly new. I expect half of them will be dead and forgotten in a year and other half will get more popular, but they're not future-proofing anything. Python always had a lot of experiments going on and will likely get more of them in the future.

Trying to predict language popularity is like trying to play on the stockmarket. Unless you can research what's really happening inside the biggest players (companies/organisations) you won't get realistic answers. Just learn what you like and what's relatively popular. Expect you'll need to learn something else in 5 years.

BTW: Go was created in 2009, julia in 2012, reasonable js (ecma5) in late 2009. Python's around since 1991 - do you really expect it's just going to disappear?

Or maybe that's just wishful thinking. I just want it to be so.

Another change that broke significant amounts of code would just make things even worse.

My objection to 3 was it did nothing for me. All I got out of it was work dumped in my lap just so my code would continue running.

Giving us a GIL-less pypy with jvm-scale performance would be worth a lot of hassle.

worth a lot of hassle to you. I imagine there are people who wouldn't find it worth the hassle. e.g. people who use python as a glue language where it's not close to being near the performance bottleneck - breaking the language to make it 'faster' would do nothing for them.

However I want to see packaging addressed as well, if not first.

Unfortunately packaging has gotten so wonky, it is easier for me to shove my small projects into huge docker containers and liberate my sysadmins from maintaining virtual environments on servers. Servers that need to be rebuilt with more modern versions of gcc and other system libs.

https://fosdem.org/2016/schedule/event/fat_python/

A pity that they did not seem to handle the business side of things well, and went down and were bought. (I'm sure there were external factors too, don't mean to say it was partly or wholly their fault. Just don't know.) Don't know much details on exactly why that happened, though I did read about it now and then, and follow Jonathan Schwartz's (last CEO of Sun) blog for a while.

http://gamasutra.com/view/news/169296/Indepth_Functional_pro...

"My pragmatic summary: A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention. Programming in a functional style makes the state presented to your code explicit, which makes it much easier to reason about, and, in a completely pure system, makes thread race conditions impossible."

Functional paradigms/languages, and immutable values, and controlling side effects, greatly help with that, in my front-line coding experience. Therefore, I am a fan.

Do you enjoy doing needless extra work? In other words, are you a little bit lazy? (in the Larry Wall "laziness/impatience/hubris" sense). If so, you should be at least trying out functional paradigms and see if they work for you like they have for pretty much everyone else who has taken them on.

But suggesting we need to start from scratch with new untested 3rd party libraries(that other people take for granted) and rewriting some of them. Even the simpler stuff like suffering the quirks of the extra tooling(build tools, IDEs) for a new language and all because of the death and doom we are supposedly seeing today(which I dont and I've yet to see people doing nightly restarts of web servers for some years). Unless you do consultancy for that language(or are seeking employment in a niche market) I think it's a little mad.

For me to declare the defeat of OOP and win of a FP language I first need to hear the voice of people having to do maintenance work on legacy code in that language as I'm too old to only believe there is such a thing as panaceea or there are only upsides to an alternative.

My thinking is that if you are so popular you can afford maybe to start 20 more 5$ instances. And really I find it hard to think of problems that cannot be solved with 20 x 5$ DO VMs at least in Java.

Writing multi-pthreaded Java apps is not my idea of a good time. I am very interested in Elixir, but at the same time recognize that in reality I use Python. And if folks want to knock themselves out writing multithreaded Java apps... to go use Java.

I think the Node model for most, if not almost everything, fits needs well with its single-threaded event loop and scaling by process. Explicitly spinning up pthreads should be reserved for systems-programming, and in which case you are probably going to be using C(++)/Rust(?).

>You'd think everybody is suddenly working with realtime stream analysis on huge datasets and are battling millions of concurrent users these days.

I almost want to archive this somewhere or put it on a plaque next to my desk.

Lisp, Clojure - CLOS

OCaml - The O is for Objective, e.g. Objects

Scala, F# - Hybrid FP/OOP

Haskell - Type classes support polymorphism and extensibility.

Erlang - Message passing as envisioned by Smalltalk

So what are FP languages that have zero support for OOP concepts and are on the rise?

Opinion aside, it's still true that some classes of algorithms are still too slow in FP and benefit from procedural mutation of state. But those should be managed very carefully as they destroy concurrency. I linked it elsewhere here but I think John Carmack's comments on this are quite lucid, and he is merely talking about using a functional style within OO languages: http://gamasutra.com/view/news/169296/Indepth_Functional_pro...

The thing is, 16-core CPU's are coming out soon, and we still have 99% of software that cannot take advantage of that well, at least within a single process.

One clarification

> Erlang - Message passing as envisioned by Smalltalk

Smalltalk, despite being called an "OO" language, did not come up with the gigantic class inheritance chains which have been attributed to OO.

While most of your examples are valid, I don't think Haskell is remotely object oriented. Type classes are not classes.

Quoting myself

> ... support polymorphism and extensibility.

OOP isn't only the C# and Java view of the world.

I realise people disagree about what exactly should be considered OOP, but personally I think not including inheritance in the definition broadens the term beyond usefulness.

https://en.wikipedia.org/wiki/John_Backus

Not taking any sides in this beef, though, just an interested bystander.

One obstacle is that Python code is often not recursive nor makes use of pattern matching.

So it all depends on what kind of Python you want to port.

A subset may be.

(see also next year will be the year of Linux on Desktop)

I think that the reality of modern scala is that, while there is in no way a unified use of the language, the way to use Scala is in its own, intermediate location. Libraries have big gains from the most exotic features that make it be closer to FP, like higher kinded types. while business code tends to look more like java with case classes and algebraic data types. The difficult part is the fuzzy middle.

Another important part of adoption is that Scala's strengths lie in a few good libraries that underpin some great use cases. For instance, using Scalding or Spark as ways to do big data, or building other kinds of distributed systems on top of Akka. For other uses, like writing simple CRUD services, there are many options, and almost all of them are bad, which is why treating the language as just a better Java just doesn't fly.

http://elixir-lang.org/

And yes, it's quite fun (and mind-bending at the same time, in a good way).

/s

Disclaimer: complete Elixir noob

It's used by a few big names (Bayard Rock, Tachyus, Jet.com, BlueMountain Capital, Microsoft Research, etc.) and it looks to be gaining more mainstream acceptance.

I predict we'll see more and more of that, but never a great breakthrough:

- appreciation of pure functions and immutability - optional typing even in Python - Garbage collection (mainstream since Java) - higher order functions - algebraic data types (in Scala, sort-of possible in C++ boost, and even in protobuf) - etc

As for Python: I think it is starting to grow again in the Linux world.

Python was always a good language because it was basically the same pseudocode we all scribbled on blackboards anyway -- with the added advantage that computers could execute it.

I just found 1.x to be unreasonable. I also find 3.x unreasonable for unreasonable reasons.

There's a lot more competition for computer languages. It might end up like Perl. More people use Perl today than 15 years ago but its importance has waned.

You really haven't addressed the issue. You simply did that dance that developers do when debating a topic. e.g. "This one is too new..." I remember when the iPhone was released, that similar misguided logic was used. Microsoft owns 20% market share and Blackberry is huge. Android was junk in its first couple of releases. Now they rule the world.

Languages like Python will have a problem because Swift and Go, for example, provide performance and type inferencing. They both just need lots of 3rd party packages. Something like a well-done cross platform F# could also prove popular. Higher level programming means safer code.

- given I have a problem, how likely is it that it's a problem in the runtime nobody saw before?

- given I want to do X, how likely is it that there's a library doing it already present? (and how likely that there's one established library rather than 10 trivial attempts?)

- if I can't find a solution to X, how likely is it that there's a solution in the first link on google? (and how likely is it that it still applies to current version?)

These have everything to do with the maturity and popularity of a language.

The iPhone / Android move is exactly what I meant about predicting popularity being like stockmarket. You've got as much information as the next person normally. If you believe the logic was misguided and you knew better, I assume you made lots of money as one of the first people to invest in the right ecosystem, right? Unless you have the weight to move the whole ecosystem, you can just choose the right solution for yourself - and most of the time it's going to depend on popularity.

Scala, F#, Kotlin, OOC, Swift, C#, OCaml have performance and type inference, and that's just some more popular ones. Python didn't have a problem because of them. (and 3 of them have a massive amount of libraries ready to be used)

Once again, you're doing that dance. Do you think I'm learning anything here? Watch out for Go and Swift. These statically typed languages are better for large projects.

Please skip the part where you explain Python's optional typing.

>Why do more people use Python over Perl?

Two factors, it came packaged by default on Linux distros and OSX. That was really a king maker in itself. Then add that the language itself is that much better in most people's eyes. People don't really like obfuscated code unless it's the only game in town (ie. the 1990's and Perl).

>Watch out for Go and Swift. These statically typed languages are better for large projects.

It will be interesting. But both have pretty big flaws so any extraordinary claims will demand extraordinary evidence of success. Neither language has exceptions. Go is controversial in its conservatism and this is likely due to the fact the entire team had to agree to add features to it. So it did end up odd in some ways because of that. Swift is in a constant state of change. Both are missing a lot of libraries. I've tried to use Go and see many abandoned projects like Martini and newer projects seemingly abandoned like Revel. The Go faithful will tell you this is because frameworks are not The Go Way, and point you to the Gorilla toolkit instead. I'm not sure I buy that story unquestioned, or not. On the whole, I'm unconvinced due to their language characteristics, that Go or Swift are ideal replacements for either Python or Ruby for webapps.

>These statically typed languages are better for large projects.

Yes, but I wouldn't want to write poorly engineered, bloated and difficult to port code even with static typing. I don't write massive 500KLOC projects so it's not a problem for me, but I have a policy of modularization with my code that would stem the issue (regardless of static typing or not). When you get to 500KLOC, there is no magic fix. Static typing, modularized code, nothing is a cure and hardly even a band-aid.

As a result of all this, I'm still onboard the Python train. I honestly do not see myself hopping off with PyPy being here today and Pyjion, Nuitka, and Pyston all up and coming. I would not be discouraged if a Rubyist either.

Of particular interest is that Microsoft is working on Pyjion and if it works out, API changes will be made to so that you download a module and JIT right from CPython3.

I'm probably more interested in Rust over Go and Swift at this point. Go is an island, similar to Java that way and not C ABI compatible, this makes it a less than ideal wholesale replacement of Python or Ruby. Swift is just too young on both the server and iOS. Rust itself is the best language I will likely never need to use, but its existence unlike most languages, makes an enormous amount of sense.

Is smartphone dying? You can use digital camera for photos, mp3 player for music, scientific calculator for math. Looks like a smartphone is being assaulted from all fronts.

That's not to say there are zero problems, but Python is so much better than all the other alternatives that this just seems like a ridiculous question.

I've been a Pythonista for over a decade, and the API scene isn't quite as utopian as you describe. Date/time handling in particular is a really poorly handled area, but there's quite a few out there.

That said, in general I agree the 'batteries included' approach is good, and the libraries _tend_ to be easy to use for most tasks. Compared to most Java libraries, it's a breath of fresh air.

Just use Arrow http://crsmithdev.com/arrow/ everywhere, all the time(s). Now your date/time problems are solved.

This means Python and Ruby aren't as much of a first choice as they used to be, even if they're arguably a lot faster for getting MVPs out.

Which is precisely why all of my new code targets Python 3 and I use PEP 484, and before that I always had type information in my docstrings. There's some places where duck-typing makes sense, but a lot of times I'm really just doing things like I would in a statically typed language so I just type the crap out of everything and run MyPy against it.

Unfortunately the runtime itself doesn't benefit at all from the type information, but I know I any of my .Net-centric colleagues can easily inherit any of the Python code I've written and be able to read it without much headache - without having to intuit what magic goes on behind the scenes, especially with things like the Pyramid request/context objects.

Which is why numpy and scipy are so full-featured and pretty damn fast.

To say NumPy or SciPy is just the sum of the libraries it uses is a bit like calling MATLAB a fancy interface for LAPACK. That really was what MATLAB was intended to be originally, but to reduce it to that is missing the appeal. As somebody who absolutely loathes MATLAB, even I wouldn't think that is fair.

The major feature of Python for me is that all its various open source modules for anything n-dimensional (matrices, image processing, GIS, machine learning, etc etc) all use the same data structure: the Numpy array. It's basically part of the standard library that is developed outside of it for pragmatic reasons. And with the speed of Fortran array operations.

That's something that only Matlab really has as well, but Python is much better in other aspects.

Yeah, I've followed Python since about 2000. For the next 5yrs there was steady growth as it displaced Perl. But it was looking quite shaky/vulnerable around 7-10yrs ago when Rails was growing fast with lots of hype.

Around that time publishers almost stopped writing any Python books at all. Look at it now though - Python is probably in the top three most popular languages for programming books at the moment. I've never noticed so much Python stuff around before.

Now that I'm moving to a more Ruby focussed devops job, I've had a look around for new modern Ruby books and I've noticed they've almost dried up completely.

While Python may be 'under assault' from a conceptual point of view, the job market would beg to differ!

* I've seen more C++/Java/C# than anything else, with a large legacy base of COBOL/RPG (yes, GMI, we're looking at you...).

* Industrial-grade quant libs (for risk, P&L, models that need regulatory approval) tend to be in C++, with the infrastructure to run them increasingly in Java.

* Lots of VBA on the desktop. Every department runs on Excel...

* Python is making inroads (see Quartz at BofA, Athena at JPM), but I suspect that it's still vastly outnumbered (by whatever measure) by C++/Java.

Some firms (and departments in bigger shops) embrace new technology agressively - at my firm I know of large Scala projects, python, big data (mainly Mongo/Hadoop), R and some Haskell.

That said, on my first job in the UK for a large insurance firm, we employed a team that wrote custom CICS machine code for Z-series mainframes. Beat that with yer fancy functional languages...

So no, I wouldn't say that python is dominant.

Where do I fit it?

http://www.simplyhired.com/search?q=ruby Showing 1-10 of 128,305 Ruby jobs

http://www.simplyhired.com/search?q=java Showing 1-10 of 190,126 Java jobs

http://www.simplyhired.com/search?q=golang Showing 1-10 of 219 Golang jobs

http://www.simplyhired.com/search?q=julia Showing 1-10 of 206 Julia jobs

http://www.simplyhired.com/search?q=%22python+3%22 Showing 1-10 of 151 Python 3 jobs

http://www.simplyhired.com/search?q=%22python+2%22 Showing 1-10 of 141 Python 2 jobs

And you know, Perl is dead.

Basically, Python gave a choice to a lot of people to either invest time into 3.x without any important improvements or to keep using 2.7 and invest time playing with other languages. Which in turn accelerated Python's decline and raised questions about it dying, promoting the idea even more. But there is no need to worry, it's not a bad thing.

I've been doing it for a while now while working on a variety of different libraries for the Pyramid project, as well as hacking on WebOb which is Python 2 and 3.

Especially if you drop Python 3.2 and lower from the Py 3.x series you have very little trouble writing code that runs on both (with a shim or two here and there).

It's not nearly as difficult as it once was.

Python users had a choice to stay in 2.7 land or make changes to their codebase for not much in return. Many chose to stay in 2.7 land, which you could safely say is stagnant. As a result, if you can't keep moving with Python, where will you go?

Since Python users have a choice to stick in 2.7 and get no rewards for it or jump into new languages that are evolving, they're going to jump into new languages and these same people are going to start saying things like "python is dead" because in their 2.7 eyes, it is dead.

Finally, unless I'm missing out on some serious deadpan sarcasm, he concludes "Don't worry it's not a bad thing" because look at Perl who everyone says is dead.

I think it's too soon to tell about the python 2 to 3 switch. I see people on here all the time making remarks about how many years its been and people still aren't on Python 3, but honestly, it's a big change and it takes a while to upgrade.

Python 2 is still supported (till 2020) and that's the line in the sand for a lot of companies. Many companies will have this in their roadmaps, but don't see a need to prioritise upgrading over other business priorities just yet.

I work at a small company for which this is the case. We absolutely will upgrade to Python 3 (before 2020), and can't wait to do so - there's loads of cool stuff in Python 3! But with a large codebase written in 2.7, this is not something we can just do in a weekend sprint. It will take several months of development and careful testing of our many dependencies. I'm sure many companies are in the same boat.

This clearly doesn't mean Python is dying. Both versions of python are still supported, and many, many people are actively using them and producing quality software. It's a great ecosystem to be part of :)

Perl is definitely dead, I think most people know that. The link was posted to illustrate that other links from that site were painting incorrect picture.

Is this really the case?

https://github.com/niner/Inline-Perl5

http://stackoverflow.com/questions/9173043/how-can-i-use-per...

My understanding is that LOTS of Python2 programs work fine in Python3 with no (or very trivial) changes. Very very few Perl5 programs will work fine in Perl6 with no changes.

As a point of perspective, there are still VB6 shops out there. That's way more "dead" than Perl or Python, but so long as the checks still clear...

This is still a very practical way to solve many problems and I'd wager for most programmers it's still the easiest way to do things. Maybe it will always be. It's hard to imagine there'll be a generation of programmers some day that finds it easier to compose dozens of tiny modules, chain callbacks with a variety of async abstractions, and implement as much as possible in tiny idempotent functions.

I feel like the worst case scenario for Python is that it will fade into the wallpaper of mature and unsexy languages like Java and C++ that nonetheless run the world and will probably be around for another 100 years at least. I'm guessing Guido would be cool with that.

A few notable solutions: 1) The C guy. Damn if he didn't blow that problem out of the water. I never want to be responsible for anything he coded. Entirely too complex, no comments, lord knows what side effects he put in place.

2) The java girl. Didn't finish. Didn't do any logging. Very logical separation of code. Lots of comments. Had to continually reference a text file in order to run the command to show output.

3) The .net guy who attacked the problem with Python. Imported a handful of libraries. Wrote 14 or 16 lines of code. Completely baffled that we would provide such an easy problem. When asked why he didn't use his strongest language, he laughed.

One of them got hired and won't have to write a single line of .net anything for a very long time.

0: http://norvig.com/sudoku.html

Point being that even if Julia is not there to replace Python, there is still a strong case for using it as a way to augment Python workflow.

What you can do in Julia that you can't do in Python is write high-performance library code in the high level language. If you need to write custom code that isn't just using stock numpy or scipy algorithms right out of the box, and needs to use custom data structures and user-defined types, Julia is a fantastic choice. You can try with Cython or Numba or PyPy, but you're either working with a limited subset of the language, or forgoing compatibility with most of the libraries that people use Python for.

Julia feels like writing Python but does not allow some of the semantically impossible-to-optimize behaviors that you can find in Python, and has a type system that you can use to your advantage in designing optimized data structures for the problem at hand.

As to my own experience dealing with data, the degree of freedom, as basically a programmer, is small. Specifically, I have to think and bear tools in my mind from the start. Which might not be ideal, but cant avoid anyway.

I use it because it has quite good numerical primitives, and I can quickly make a slow, Python-like first pass at an algorithm, then profile and get C-like performance in the bottlenecks with minimal effort. And if I need a particular library, I can call Python's. Also: macros and multiple dispatch make a big expressiveness difference for my type of work.

C++17 also feels surprisingly dynamic, and together with Cython for easy Python-C++ interop also decreases the need for Julia.

And reports from the Julia world are not exactly encouraging - http://danluu.com/julialang/

[1] https://news.ycombinator.com/item?id=11070764

Here's the breakdown by which Pythons were used to download from PyPI in the last two weeks:

  2.7     85.90%
  2.6      6.66%
  3.4      4.64%
  3.5      2.09%
  3.3      0.56%
  3.2      0.12%

https://www.reddit.com/r/Python/comments/45sm94/what_are_the...

I don't doubt that python 2.7 accounts for the majority of the downloads, but I sincerely doubt 2.7 usage is at ~85%.

2.6 usage is probably almost exclusively RHEL/CentOS 5/6 system pythons and not representative of actual projects.

Also pip itself got upgraded to use caching by default not that long ago. All distributions defaulting to python2 will still have old pip which redownloads your packages on every installation (`tox -r` for example). More recent distros will give you tox which caches the downloads locally (which lowers the numbers).

Pypi also doesn't count private repos. If openstack started testing commits using pypi repository and turned off caching, I'm guessing it would add at least 10% to python 3.4.

TL;DR: pypi stats are interesting, but don't rely on them to give you precise answer.

    Be aware that PyPI isn't a great way to get accurate statistics. 

Statistical sampling is based on the premise that your sample is randomized from the total population; I would argue that the stats from pypi represent a reasonable random sample of python users around the world.

Certainly, you can argue otherwise... if you care to provide some meaningful alternative statistics?

In other words, it is neither random nor representative of python 3 usage, failing the premise you yourself mentioned.

There's no easy way to determine Python 3 usage overall. Your best bet is to go around polling companies of all sizes as well as indie devs. What you will find is that:

1. Some amount of people still use Python 2.x because they don't know any better

2. Some amount of people want to use 3.x, but still use Python 2.x because of incompatible dependencies.

3. Some amount of people (companies mostly) still use Python 2.x because a migration to 3.x is currently too costly.

1 -> This is partly caused by FUD. Hating on Python 3 has become a popular past time of people who don't know how to be productive otherwise. It's also caused by the very high amount of tutorials etc around the web that "require" 2.x because, for example, they have an unparenthesized print call (relevant XKCD: 353). Arguably this is one of the big failures of the 3.x push.

2 -> That number is constantly diminishing as more dependencies become available on 3.x. The most recent big win is Scrapy, a massively popular scraping framework, which just finished its 3.x port a couple weeks ago. It's an ongoing process - we are in a much better state than we used to be, the Py3WOS is looking almost entirely green.

3 -> This number is mostly irrelevant as it tends to be in closed ecosystems. So maybe CloudShareBuzzr Inc. is using Python 2.7 internally, but they don't produce anything open source so it doesn't affect the rest of the ecosystem. As new, major features are constantly added to Python 3.x (venv in 3.3, pip in 3.4, async def in 3.5), eventually the cost of switching will be worth it.

It does matter because that means if you ever want to do it as a job, you HAVE to learn Python2 for that gig at CloudShareBuzzr. Paying your bills is always going to top using "the latest version" of anything. I'm not sure why people ignore or miss that point.

Python3 is the optional language, 2 is mandatory if you want to get paid.

Learn that print doesn't need parens anymore, a few renamed modules, that Python 2 str is mostly equivalent to Python 3 bytes and Python 2 unicode is mostly equivalent to Python 3 str and you're most of the way there.

Let the tech live or die based on its actual merits (employment, technical etc), not trying to get more people onboard with propaganda. Considering the money is with 2, I think what you said backs it up even more. 3 will be easy to pickup when needed.

(cue the downvotes)

Seriously. List one feature Python 2 has that Python 3 doesn't?

People already know it?

The most used?

    ...it is neither random nor representative of python 3 usage, failing the premise you yourself mentioned.

Can you actually justify these assertions?

Or are you just speculating because you don't like the results?

    Your best bet is to go around polling companies of all sizes as well as indie devs. 
    What you will find is that:

Come on. Now I can't take you seriously at all.

You know what they're going to say already, without even asking?

You're just speculating.

Stats > guesses.

Even if the pypi stats aren't completely reflective of the entire ecosystem, I'm going to argue that they give a pretty decent impression of it, regardless of the mild bias that you've listed above but can't quantify.

Yes:

- It has been done before

- I've been around the Python ecosystem a long time and I know a lot of its users (a random sample, if you will)

- I spent several years freelancing as a Python dev which gave me the occasion to do exactly that. While that is not a representative sample on its own, my data matches up with the rest.

But all things aside, you really need to check your damn attitude at the door. I neither like nor dislike the results. The facts that matter are that Python 3 has a great ecosystem today and that is what matters to me; not whether my neighbour uses Python 1, 2, 3 or PHP.

My only point is, was and remains, that statistics are more complicated than simply 'those statistics do not match my personal perception of things'; justify your argument with actual data.

I'd would be interested to see any alternative stats on the subject you care to link to.

What you're left with is polling, and I gave you insight (backed with my own experience which, yes, is actual data) into what you might find if you went that route. I have no actual numbers on such polling because my samples are too small to be useful. All samples are too small to be useful at this point.

The reason I brought up the health of the ecosystem is because you seem to think I'm biased, or lying, or maybe I'm just a bad person and like one version more than the other. I was just trying to remind you that it's a language version, not a presidential candidate.

There are no good stats that give an accurate representation about usage % of each python version. PyPI is the only proxy we have, and that is skewed by a number of factors (two of which I mentioned). The overall trend is probably accurate, but exact percentages certainly are not.

My like or dislike for python 2 or 3 has nothing to do with my comment upthread. I was simply stating a number of facts about the data that people can take or leave as they like. It was not "convenient" for me to share those facts. I simply thought people might want to be aware that there's nothing scientific about the aggregated percentages.

It's been a lot of years, but people are slowly and finally starting to migrate to 3.

It could be worse. I'm still waiting for perl6 because those guys got caught up in Haskell hell.

It's dominance of science is why Python has 25% science talks this year at PyCon, and why we see articles like: http://www.infoworld.com/article/3012442/application-develop...

But yes, if you didn't know any languages, then of course you should invest in an immature language with no mature libraries for the tasks you need to complete, because you were given a few months of extra runway time by your boss to fill-in the library ecosystem instead of getting your job done. We'll ignore that PyPy places you damn close to Go in terms of performance (except with mature proven libs), and that usually your task won't be CPU-bound anyways (the GIL release on I/O tasks)....

Why do troll questions like this even hit the front page of HN?

If someone wanted to get into building web apps would Python be a good choice?

The answer is likely to be colored by your experience. I'd say yes, it is losing ground to other languages in the context of programming for the web. The people who use it know why they're using it. Othetwise you don't see many coding boot camps teaching Python. It's all about Ruby and Node.

But is Python dying? Not by a long shot. It's just getting less attention right now because of some of the other new toys that are making a lot of noise right now.

I consider this a troll question because frequently I see HN questions like this completely disconnected from programming communities at large (which do not participate in HN), extrapolated to the wider web of all programmers. By this factor alone I'd expect Java to be completely obsolete by now.... but obviously no one is oblivious enough to reality to suggest that.

As for that question, if you want to build webapps right now, then yes, Python, as well as Ruby, and PHP, would be absolutely fantastic choices. The library ecosystems for all three of these are incredibly rich, mature, and well supported. Choose the language of these 3 that appeals to you the most, you will not be disappointed. I'm not going to tell you which one to choose, I think you'll be happy with whichever of these 3 languages appeals to you the most.

If you don't mind filling in the occasional gap, and like the bleeding edge of newness, try Rust, or Go. I've done both, they're fun languages with interesting paradigms (built-in lightweight threads vs. memory-safety at all costs FIGHT!).

Getting less attention? According to what? Did you see the the link about dominating science? Attention according to what group of people?

21% of the Internet uses Wordpress, which is built with PHP.

The only concern I have for Python is exactly the temptation to keep adding features and chasing other language's tail lights. I've recently gotten the chance to see a fairly novice programmer dip toes into some Python-based testing code, and it's definitely gotten pretty easy to make awfully magical and complicated Python code after all the decades of accumulated features. They get a very different experience with Python getting the whole thing dumped on them at once than I did riding with the language from roughly 2.0 and watching the features come in one by one.

Python has many advantages over, say, Go right now, but the advantages that Go has over Python, Python is not in a position to reasonably add to itself. Is it "future-proofing" Python, or is it taking something already pretty complicated and crusting on one-too-many layers of "features"?

Exactly, one could use the same criteria of the OP and conclude C is "dying", and how wrong they'd be.

Just because it seems like there isn't new and hot stuff for Python doesn't mean it is actively used and sought after today. Perhaps it's strange because Python always seemed like the hot new scripting language thing until it now where it has become the well known scripting language thing it is today

And you realize it when you explore the QUALITY of python libraries out there. You know what I mean. Quality in Python code sucks.

Python I'd say is in a similar boat. Strong and established with tons of libraries, not popular amongst the kids.

Edit: Apparently my use of "kids" as a sarcastic way of referring to those who won't use "old" languages was missed. :)

Python was doing just fine until Python's little tin god came up with Python 3 and tried to drive a stake through the heart of Python 2. That backfired, badly; six years on, Python 2 still has far more production use than Python 3. (No, it's not about Unicode. Python 2.6 and later do Unicode just fine. I've written sizeable all-Unicode systems in Python 2.6. It's just that in 3.x, it's the default.)

Coming up next, Python 4, with typing syntax that isn't checked. Ugly typing syntax - some in comments, some as annotations. There's an argument for optional type declarations that are checked, but unchecked declarations are trouble waiting to happen.

The PyPy crowd has brought off a miracle - an optimizing compiler for Python that supports almost all the dynamism of CPython. It took a long time, but they did it. CPython should be retired now, or made to conform to PyPy. But no; the little tin god insists that his CPython defines the language. The PyPy developers struggle to keep up.

The language isn't the worst problem. It's the wildly variable quality of the libraries. The great thing about Go is that it has libraries which are used internally by Google, and thus have been executed billions of times. Python's PyPi (formerly Cheese Shop) has no quality control, and many versions of very similar libraries, each with different bugs. There's no convergence.

ISO Standard Pascal is useful mostly as a teaching language. You can't do much real work in it. So Pascal fragmented, badly. There were lots of incompatible variations. In time, Pascal was abandoned.

Sometimes the original language guru has to be pushed aside before they run the language into the ground.

[1] http://www.pascal-central.com/docs/iso7185.pdf

[1] http://www.ryan-williams.net/hacker-news-hiring-trends/2016/...

It's a bit dangerous bias/distortion, you can easily trick yourself into thinking that everyone is running everything with docker, soon everyone will be spinning up clusters with tensor flow to compute on their petabytes of data :) (nothing personal, OP, just something I've noticed lately).

Python is a beautiful language, and what I like to call programming at its purist. It removes the distraction of syntax from the task of problem solving. It's simple enough that a 7 year old can grasp it, and yet powerful enough that Google used it for its TensorFlow's API. Python syntax is so close to pseudocode, that I'll often code a solution in Python, see that it works, and then recode it in Java. It's difficult to describe if you haven't spent 7+ years using Java, but it's way more satisfying debugging Python code than rewriting solutions in Java.

I still use PHP and bash a ton, will use Java in school next semester, used C# during my internship, but Python is among my core tools right now. I notice that library support for Python is so, so much better than for PHP, making my life a lot easier at times.

As for Go, I still intend to look at it, at some point in the future. Basically like I intended to look at Python three or four years ago.

Javascript, yeah for in browsers.

Julia? I heard of it but I still think of the girl first and the language second. Never looked at it and don't see it come by that often. Data science you say? I thought R was hot there, a language I was going to look at somewhere in the next few months (my girlfriend will get it in university, good opportunity for me as well).

Pip is just OK. It feels like it's missing something. Could be a simple lack of experience still. I haven't found anything like Gaurd yet and yet to find a replacement for rack and NPM 's simple package.json. There is setup.py but it feels harder and wrapped in mystery still and doesn't work universally the same for Python 2 and 3 which I have been causing some road blocks and extra cycles being wasted.

Most of all I hate the backward compatibility issues of Python 2 to 3. I rarely have issues running older Ruby or Java code in newer versions of the language. It seems ridiculous that it's been a little over 7 years and people are still fighting with issues between Python 2 and 3 and you still need to pick a version to use. Sure you can code around it, but why the interpreter doesn't handle backward compatibility with deprecation statements is just amazing to me. This isn't a new thing. Languages like Java and Ruby do it as do plenty of others I'm sure if you wanted to make a syntax change you can handle the code in the interpreter and issue warnings to uograde them without breaking all old code bases.

But any ways, I digress, I don't think Python is going anywhere. Too many people and companies use it. It's got a lot of good libraries and and if you just start with Python 3 it's language is just like any other programming language. It's got some things you have to get used to that are unique to it but in the end, you can make it do what you need.

I personally think Ruby allows for nicer looking code and readability, and NodeJS has a far better Eco system. Hell, Languages like Elixir feel like a nice mixture of both with the huge added benefits of being highly parallel at the VM layer.

PyPy seems like a better place to invest resources since the JIT can really speed things up.

That's my 2 cents.

Have you ever actually used Ruby?

Here's what FizzBuzz looks like in Python:

    def fizz_buzz(number):
        if number%3 == 0:
            return "fizz"
        if number%5 == 0:
            return "buzz"
        return str(number)

    for num in range(1,101):
        print(fizz_buzz(num))

People on HN keep saying Ruby is intuitive and easy to learn -- no it isn't. The Python code by contrast is basically the same as the pseudo code you would write on a napkin in "not-any-particular-language-I-just-want-to-describe-an-algorithm-without-language-specific-issues-to-get-in-my-way".

[1] http://hostiledeveloper.com/2014/04/26/on-why-learning-to-pr...

  def fizz_buzz(number)                                                                                       
    if number%3 == 0 then                                                                                     
        return "fizz"                                                                                         
    end                                                                                                       
    if number%5 == 0 then                                                                                     
        return "buzz"                                                                                         
    end                                                                                                       
    return number                                                                                             
  end                                                                                                         
                                                                                                              
  for num in 1.upto(100) do                                                                                   
    puts(fizz_buzz(num))                                                                                      
  end

(Also your code is wrong - it never prints "fizzbuzz" which it should for 15, 30, 45, etc.)

I think Python could easily be replaced --- for greenfield projects --- by something better, but there's nothing better right now, and more and more people will keep using Python for that very reason.

`','.join(pieces)` just seems unnecessarily weird, and present simply for OO's sake. Not everything needs to be some object's method.

    >>> phrases = [['a', 'b', 'c'], ['d', 'e']]
    >>> print(list(map('-'.join, phrases)))
    ['a-b-c', 'd-e']

- Non-performance-critical command line tools for game-data export-pipelines that I previously wrote in C/C++: Python code is usually more compact, and everything I ever needed is in the standard library. If performance is critical I still prefer python to call out to minimal C or C++ tools which do the heavy-lifting.

- Replace native shell-scripts and Windows batch files with portable python scripts that run on Windows, Linux and OSX.

- Stitching together 3D content-creation-tools and command line tools, most DCC tools of have become python-scriptable in recent years.

- Code generation for C/C++ and shader code.

These are all very pragmatic and simple things, I don't care whether my python scripts are 'pythonic' or elegant, and I don't care about the 2 vs 3 debate. Python gets the job done, works everywhere, and I enjoy writing it because of its friendly syntax and powerful standard library.

Python strikes an amazing balance in being a rapid development but also sustainable language, that makes for maximally maintainable code.

While I can't speak for it's growth in data science, it's widely used in systems programming and web development and web services as well.

Go is simply not as agile, it's a lower level systems tool for "tight" low-level code, yes.

Python has never been a front end language. I still think Javascript is a HORRIBLE language, but that's beside the point.

At least from my experience, it's exactly in the perfect sweet spot of language design for being unexciting and getting massive amounts of work done.

A tad bit old, but read this: http://www.curiousefficiency.org/posts/2012/10/pythons-futur...

TL;DR: No.

My take is Python 3 has done more damage to community than we accept to recognise. Python 3 has taken a strong academic approach to make the language better while being valid made it feels like a regression compared to Python 2. The 'print "abc"' not working anymore without brackets is a good example of it.

If the above is true, the Python language has outlasted the Python developers - like C.

Bottom line is that performance does not predict whether a language will die or live. That's not what most people care about.

Actually those 3 things are much simpler in Go.

I've always used Python, but I'm starting to wonder if I didn't back the wrong horse. I've been dabbling with Erlang as my side-language for a years, and Elixir is extremely intriguing to me. I'm considering using Ruby for a new project simply because the syntax is closer to Elixir. A Ruby+Elixir shop makes a ton of sense.

I think the better question would be "is Python losing focus?". The answer to that would be yes. Which includes not only the ~8 year Python3 debacle that's ~10% complete from a usage standpoint, but also the Python3 feature soup. They've just added a 4th string formatting method in Python 3.6.[0] I don't even have words for Python3's feature soup, it's absurd in its own right.

[0]http://learning-python.com/books/python-changes-2014-plus.ht...

My opinion: Python will outlive the three languages you list. But it's dying outside data science, and maybe even there. Optional typing can't compete with modern type inference, and there is too much dynamism in the existing Python ecosystem (even though it's so rarely used - there's not a monkeypatch culture like in Ruby - it's used often enough that you can't just remove it). But not today, probably not in five years either. In fact with the community finally having rallied around 3.x this is probably the best moment in years to leap into Python.

But yeah, all languages are dying, some faster than others. You have to make your own judgements, and learn general skills so that you're not bound to one particular language (unless you're very confident in that one language).

If you want truly survivor languages look at Smalltalk. More than 30 years and still alive. Is not about modern type inference or dynamism... it's always about the people. And people in Python doesn't have that commitment with the technology, they are more like freeloaders.

Machine learning also, at least from my academic view, seems to be dominated by C++/Matlab/Java/Python (and things seem to be moving to Python).

But more broadly, you'll have to learn dozens of languages as a programmer anyways. I wouldn't get too caught up in Python vs. other things.

Look more at what you want to implement, then see if Python makes sense as a language.

Additionally Python should then allow the (explicit) casting of WTF8 datatype to bytes and from bytes to WTF8 datatype (edit: note, I mean invalid data would be read, stored within a WTF8 datatype as such, then converted /back/ to an invalid UTF-8 bytestream identical to the one read in).

The main reason that Python Unicode handling is broken is that it creates problems that aren't necessary to exist or solve. In the real world, you encounter unvalidated data; and many times you don't /care/ if it's valid. It's just some human name for a bytestream. Or some not-quite valid Unicode stored within a file, or maybe something else that you want to handle like a bytestream but pick matching Unicode bits out of.

If you are starting your own company or a side project choose a language that a) best suites your needs and b) you know. Unless your goal is to learn a new language you probably don't want to write your business logic in a completely new language just because it's popular at the moment. And outside of stuff you actually have a say in (i.e. stuff you do for your employer) it doesn't matter what language(s) you know as long as you know something that's applicable.

I learned PHP as my first language (well, I wrote some VB stuff for school before that, but I never wrote it on my spare time), after that I went on to JS just before college and in college I learned C#/Java, but also for my web side projects (which I made some money from) I learned Ruby. Now since graduating I've also dabbled in Python and very lately little in Perl6 (just because the syntax looks so nice), but for my actual job I'm mostly working with Python. It's not my favorite language, but my Ruby and JS (as well as general programming knowledge) carries me through the tasks, it's not like I'm in completely different world where I can't function.

My point is as long as you know how to program the language shouldn't matter, obviously jumping from something like Python to C++ is a bigger change than going from Ruby to Python, but it's not imposible and if your employer really just cares about your languages they are either super specialized and doing some weird shit (which might be your thing and then all you can do is to learn that language) or they really don't know what they want/need.

I'm very excited about Elixir for example. There is a new Elixir blog post/article/github repo posted on HN every day, you would think that Elixir is the new cool thing. Well, not easy to find companies that actually use it.

It's built on technology older than Java. I'm not sure most people need what it offers immediately, but it's certainly a safer bet than most new things. Including CPython3 and Perl6.