Hacker News new | comments | show | ask | jobs | submit login
Ask HN: Is Python dying?
240 points by tanlermin on Feb 14, 2016 | hide | past | web | favorite | 348 comments
Go for systems and backend, JS for frontend, Julia for data science.

It seems python is assaulted on all fronts..would now be a bad time to invest in a python stack, or will efforts to future-proof python (numba, blaze, nuitka, pyjion, Django channels, pyparallel) bare fruit?

That may be a view through the distorted HN lenses. Spend some time on Lambda the Ultimate and you'll think imperative programming is dying.

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?

My prediction is that one day some alternative Python interpreter (Stackless, or GIL-less, or which compiles ahead of time to machine code, or something like that) will go from being merely an interesting concept to a dominant runtime. Python is such an excellent language, and it only has a small handful of elements holding it back from being even better. I feel like eventually something has to give, and either there will be a radical new official Python runtime, or an alternative one that becomes the de-facto standard (Pypy, Jython, Cython, Stackless, etc).

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

I totally agree with this. I think the Python community is becoming increasingly aware that this is the next major fix. I thinking 3-4 years before we see it, but we need to stay vigilant and make sure it happens.

A slightly leaner object model with a fast runtime would make it perfect.

Anything that breaks code AGAIN will kill the language for sure.

Not sure why you're getting downvotes. The 2 vs 3 has already split part of Python's userbase.

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

I'm not sure that's true.

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.

> My objection to 3 was it did nothing for me...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.

the people using it for glue code really won't be upgrading their version anytime soon. My team uses python in production and we are still on 2.6

And you'd now have a 3-way split of resources (both learning materials and developers) between 2, 3 and (an imaginary) 4.

I completely agree. Fixing the run time would be a large effort to addressing one of the big complaints.

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.

Interesting. What's the size / overhead of a Docker container? Not familiar with it, though know what it is, and that it is smaller than a complete VM.

It depends on the Linux distribution you use. Using Alpine Linux as a base can keep the overhead as low as a few megabytes.

Got it, thanks.

Have you tried nuitka or Conda?

It's unlikely unless someone with deep pockets steps up, such as a corporate benefactor. But it will continue to improve as it does every other year.

FATpython is starting to become some of this.


Yes, one reason for the success of Java was the huge amount of investment Sun put into it - in both marketing and tech improvements. I read that they spent millions on that. And it did result in benefits. Across the span of some years, anecdotally, the performance of Java apps improved a hell of a lot - I remember noticing it, say maybe from 1.2 to 1.6 or so. E.g. some servlet + JSP based app running a lot faster at the end of that period than at the beginning.

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.

Object-oriented languages are Dead Men Walking due to the problem of global mutable state management in any medium- to large-sized codebase, coupled with dependency/inheritance hell, leading to complexity hell, leading to geometric progression of tech debt. Compounding this is the lack of good unit test suites across the board, meaning that even if you write absolutely perfectly tested and maintainable Python (or Ruby, or Java, etc.) code, you still are stuck using libraries that have not been written with that in mind.

And yes, I'm talking broadly about the rise of FP.

Yeah they will still probably be labeled as dead man walking for the next 20 years long after your FP langue de jour will have outlasted it's pristine days and got damned to hell by the devs having to maintain the programs written in it. Don't get me wrong if you are currently doing consultancy business for a niche FP language far for me to blow the wistle to companies that instead of paying your fees and hefty salary for that rare programer(who might be me) who would have dabbled in your obscure language they would be better of paying 10$ a month and get 2 more DigitalOcean instances to support the rise in traffic your non sharable state code is solving.

I don't think so, this time:


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

Well I don't think functional languages are something new and by reading the latest death and doom I'd wonder how we ever got this far and why suddenly it's so much harder to do concurrency. I confess that I don't write low level software for lunar modules but just the regular enterprise stuff and having worked with high level concurrent constructs like ConcurrentHashMap, LinkedBlockingQueue, RingBuffers on the jvm I've yet to experience the concurrency issues everyone is lamenting. I know it must be hard for the people developing the jvm to make those high level concurrency constructs available for me, but that is why I'm grateful for their work and "happy" that I can rely on them. I don't know maybe I've just been very lucky until now.

Most of the bugs I see in the wild are of the "runaway state" variety; in other words, a state the programmer(s) involved forgot to imagine might happen. This class of bugs includes EVERY bug or crash that is fixed by a restart of an app or system (because all that does is reset state to a "known" a.k.a. "modeled" state, bringing it back within the code's, i.e. programmer's understanding). Therefore, anything (whether it is a language, a methodology, or both) which mitigates or eliminates this class of bugs would be HUGELY valuable.

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.

I'm going more pragmatic and I think most of the bugs were/ are NullPointerException the kind that today's IDE(due to their maturity of working for years and years with the language) can now even warn you about, compared to obscure ones that force you to do resets. On the other hand I don't see why the concepts of immutable values cannot be adopted in OOP languages. There is http://javaslang.com/ and immutable collections were long time present in Guava library. Sure immutability might not be enforceable in the language itself but you can do it. Java8 has streams for a functional approach to collections. Hell you can even use Akka if you cannot do without an actor framework in java.

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.

If you're working a problem capable of being solved by two $10/mo DO VMs, you're working a problem that can be solved in /any/ language.

I'm amazed by the number of people that declare the shared mutable state of the current languages as their bottleneck. You'd think everybody is suddenly working with realtime stream analysis on huge datasets and are battling millions of concurrent users these days.

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.

Your comments are probably not intended to make anyone laugh but I'm enjoying them. But what you're saying is so true. I'd like to take it a bit further and add there's a reason while the implementation is slightly barbaric, Node.js continues to thrive. While I don't use Node, I have, and tend to think making things even more 'regressive' than say, Java, is the right way forward for most work.

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.

You mean all those FP languages that happen to support OOP as well?

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?

Being a "hybrid FP/OOP" language is like taking a pure soup and allowing anyone to put a little bit of fecal matter in it and still thinking the product is "A-OK." ;)

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.

>Haskell - Type classes support polymorphism and extensibility.

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

Any Haskell coder knows that.

Quoting myself

> ... support polymorphism and extensibility.

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

Polymorphism and extensibility are features of OOP, but Haskell implements them in a rather different way to most OOP languages.

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.

There is no disagreement, Smalltalk is the object system. Object-orientation was invented in Smalltalk. Other languages and systems are just poor imitations.

To be pedantic, Clojure has nothing to do with CLOS. It does leverage JVM and lets you use objects and OOP patterns though.

So where do you think multi-methods and protocols come from?

Okay, TIL, still there's more OOP in Clojure beyond CLOS influences.

Object oriented does not require state: it requires encapsulation. I incorporate as much immutability into my code as possible and I would say most of our objects never have their state changed from instantiation and I write Enterprise Java all day long.

Interesting that FP started from as long back as the time of John Backus (of Backus-Naur fame):


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

This either or thinking is not very productive. FP existed before OOP, it's hardly reasonable to think it will replace it.


I really want ZiPy to take off, a fast Python 3.5 for the JVM would be lovely.

MicroPython is already pretty much there on some fronts.

Would it be possible to port it to the erlang-vm?

The Async stuff, generators & yields surely. Maybe even yield from.

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.

Not a good fit. Too imperative/oo to fit into Erlang's functional world.

A subset may be.

Next year has always been the year that functional programming will take over the world. It's been like that since I started programming in the early 90s. While functional concepts have leaked into imperative languages, Haskell is the only pure functional language that so far has come close to breaking out although Lisp has also gotten close a few times.

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

Clojure and Scala have gotten close as well. I've seen Scala in use at scale at both universities and corporations. Clojure is being used in production by at least a few well known companies, too. Both have the primary benefit of being backed by the JVM.

Scala seems to have some momentum. I've wondered if the companies that have adopted it are using it like jvm haskell or a just a better java?

Few people are treating it like jvm haskell in production, although a certain subset of really loud people wish it wasn't otherwise. They all tend to work in the same OSS projects, while the rest of the community does their best to pretend they don't exist.

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.

Actually sealed traits and case object/case classes and pattern matching is really useful for http programming.

Verizon is one of the bigger scala shops (a few hundred scala programmers on a "project") and is much closer to the functional side than a better Java. However, micro services and good library support mean some of the less experienced teams (in FP) use it more of Java++. Both are very pleasant to maintain/work on though.

This is just one [massive] project, but HMRC are rebuilding in Scala atm, & from talking to the developers working on the project, bit of both: selling it as a better Java with all the associated interop with existing stuff, but individual devs attracted by the functional side. The Guardian seemed to have similar reasoning.

Third option: like a JVM ML.

With the popularity of Apache Spark in big data, Scala is definitely gaining a lot of traction.

Elixir is promising.


And really enjoyable... That's what really counts right?

Couple that with Phoenix (which looks and acts like most other MVC frameworks [and has good docs]), and we have a win I think.

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

Clearly you haven't worked with EXRM and the 'no documentation outside hello-world' Ecto query.


Seems comprehensive: http://hexdocs.pm/ecto/Ecto.Query.html

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.

Jet.com does a ton of F# advocacy here in Silicon Alley

> While functional concepts have leaked into imperative languages, [...]

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

Pure FP might not have taken over the world.

But those that read my Java, C# and C++14 code, better know their way around lambda calculus.

Take off the HN glasses and PHP, Java, C# and loads of other 'old' languages are still huge.

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

Reasonable Python is much younger than that. (Only fair, if you make an adjustment for reasonable js.)

ES3 is probably the real cut off for JS.

October 16, 2000

Just googled it, it's the release date of Python 2.0.

What was so unreasonable about 1.5? That was my first python and it worked perfectly fine.

Old style classes. No way to subclass built-in types. No metaclasses.

Sure, but non of those things made it a bad language, or where really unreasonable things to have left out.

There is a big difference between unreasonable and bad.

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.

For me it's lack of lexical scoping.

When people say dying, they never mean it's just going to disappear. The hit-and-run on Go being a new 7 year old language seems unfair. It has great performance and has proven itself in production.

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.

The age makes a big difference for at least these reasons:

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

Massive library. That was Perl's big advantage. Why do more people use Python over Perl? F# isn't really cross-platform yet. Swift is 18 months old. Scala is a bit complicated for many and slow to compile. C# was a Windows only language for a long time, with Xamarin for those who really really need limited cross platform support. OCaml never gained much traction. If Microsoft had used it instead of a slightly different F#...

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.

Thought-provoking post. The responses below are my opinion, but I do think there is a good chance they're the opinion of the majority.

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

Thanks for the post. I share your frustration with the way developers discuss these issues.

Not to mention, the question sounds like this:

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.

We use python it is our primary language

Not only is Python not dying, but it's stronger than it's ever been. The majority of top colleges are now teaching CS using Python. It's completely dominant in academia, finance, and startups. It has the best libraries and documentation of any language. And Django has arguably the strongest community of any open source project period.

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 wouldn't say Python is dominant in startups across the board. Though it is strong in data-heavy environments (with all it's issues nonetheless).

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.

> Date/time handling in particular is a really poorly handled area

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

Couldn't agree more. Developing for the last couple of years code that is highly sensitive to dates and time, and Arrow saved my life.

I think there's more of an interest in scalability and compile-time checking among startups nowadays, hence the shift from dynamic languages to lightly static languages like Go or all of the type-checking and Haskell-derived JS variants out there.

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.

> I think there's more of an interest in scalability and compile-time checking among startups nowadays

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.

> Though it is strong in data-heavy environments (with all it's issues nonetheless).

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

Techincally, Numpy and SciPy are C and Fortran extensions to Python, not Python code.

I'm not sure if that's the best way to describe them. IMO, NumPy/SciPy are probably best described as Python wrappers for a wide range of C and Fortran codes, but they add quite a lot of value on top of that. If you've ever used e.g. LAPACK or VODE directly, you'll probably have horrible memories that you prefer not to recall. NumPy and SciPy have a large contribution in that they unify (admittedly, neither is really a paragon of consistency, but...) a huge range of disparate libraries under a much more accessible interface.

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.

Libraries are what make a language.

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.

> Not only is Python not dying, but it's stronger than it's ever been.

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.

Agreed. It's much easier to hire for Python skills today than it was even 2-3 years ago.

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

Completely dominant in finance? Do you have a source for that claim?

Actually that's probably not accurate now that I think about it. Python is mostly used by quants and people figuring out what trades to make, as well as for some of the internal business tools. Whereas the people building the actual exchanges are probably using Java or C++.

"Finance" is such a broad term with respect to IT - you'll find anything if you look hard enough. The following is based on my experience only - I'm sure there will be lots on here with different experiences:

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

I hear BofA are back pedalling on Quartz. Kirat has left, and there's some new senior IT mgmt who don't want to put all their eggs in one basket. Just gossip, would be interested in any confirmation/refutation...

Im an economist who loves to program (especially in Python, but I'm not married to it), and I detest Excel.

Where do I fit it?


I keep seeing Clojure come up in relation to banking, and occasionally in relation to hedge funds.

Can confirm, am a quant.

His rear end I suspect, I saw more Java, C++, and .Net in finance in my time.

You must be joking!

http://www.simplyhired.com/search?q=python Showing 1-10 of 169,970 Python jobs

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

http://www.simplyhired.com/search?q=perl Showing 1-10 of 220,528 Perl 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.

... python 3 is a really a fairly small effort to learn when you know python 2. You'll learn most of what you need to know in a few days, tops. This comment feels extremely disingenuous

I used to write a lot of python, and the hard part is that as you write code you're pulling in more and more external libraries, and sooner or later one of them will be incompatible with python 3. Then if you want to continue using python 3 in your own code, you need to spend the effort to port that library to python 3.

You don't invest time to learn it, you invest time by writing or converting code.

Writing code for Python 3 and 2 isn't that difficult.

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.

Your snark was somewhat incoherent. Can you be more clear? guessing from the cpan in your name you're a Perl person?

It was coherent and I would not define it as snark. You don't comprehend his point yet you have the wherewithal to label it as incoherent & snarky -- that's snarky. But I digress..

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.

> if you can't keep moving with Python, where will you go?

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 :)

Maybe you think you "comprehend" his point because you decide to interpret it in your own way. But it was not coherent (and honestly I'm not even sure if that was a snark in there or not, mostly because it was incoherent).

No, it was interpreted pretty much correctly, except for the Perl part, which I should clarify.

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.

How is a tool like Perl dead when it's still heavily used on hundreds of thousands of machines all over the world? Is C dead as well? I would say, a tool is dead when it's no longer in wide use. Perl is hardly in that category quite yet.

It's dead because new projects aren't started in Perl unlike C.

Your point stated more generally is that while C is the best tool for a wide set of use cases, for each of the one-time use cases of Perl there is now a better option

Are you saying it's a better investment to jump to another language altogether than to jump from 2.7 to 3.5?

It wasn't incoherent to me - he used Perl to argue that just because a language has a high number of open jobs on simply hired doesn't mean that the language is not dead.

> Showing 1-10 of 220,528 Perl jobs

Not really. On page 18 you already have jobs like http://www.simplyhired.com/job/net-developer-job/compugain-l... were Perl is just used as an example for scripting languages.

The exact same could be said about Perl 6 ;)

It can't be said - Perl6 is completely different language and brings a lot of desireable features on the table. The problem is that it is not so easy to port Perl5 code to Perl6 as porting Python from 2 and 3.

> The problem is that it is not so easy to port Perl5 code to Perl6 as porting Python from 2 and 3.

Is this really the case?



Yes this is the case; Through libraries we are trying to make it easy to CALL perl5 (and ruby and python and...) modules from Perl 6. But porting -- aka translating -- is another matter. Mostly it requires a similar amount of effort as if you are translating your program to any other dynamic language for nontrivial programs.

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.

While this is true, a good deal of porting could be managed by packaging up old code into Perl5 modules and using Perl6 to glue it together, no?

Keep in mind that scripting languages are often mentioned in job postings as secondary skills. There are TONS of "Java/C++ developer, would be nice if you knew some Python or Ruby" which get counted as "Python jobs" when you do something like this.

And if you look at Rails vs Django, while some say Ruby is dying, the job market is definitely in Ruby's favor in the webspace. The thing is even posting this generates more hype for Python, even though it was researched rather unscientifically. It's marketing.

http://www.simplyhired.com/search?q=perl Showing 1-10 of 220,326 Perl jobs

Wow that is a surprise. No-one even seems to talk about perl anymore.

They're too busy getting paid writing Perl.

lol .. It's still pretty shocking. I know lots of programmers, including some that used to write lots of Perl, and none of them are still working on it. Those job numbers are crazy.

Could it be that there's so many open Perl jobs because there are no programmers to fill them?

There are a still Perl shops out there. ZipRecruiter (where I work) and Booking.com are probably the biggest Perl shops in terms of Perl Dev headcount but I could be unaware of another company that's as big or bigger. There are a number of small to medium size companies in LA that are primarily Perl based and The Rubicon Project has a bit of Perl on the web side and C++ and Java for their ad network. Perl isn't dead, it's just not the hot new kid on the block by a long shot.

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

I think Rentrak in Portland is still an all Perl shop

Last time i interview also asking for perl and some automation adobe . I only used perl in 2001. Currently code in PHP and C#. Now thinking back, i need to relearn PERL again.:P

http://www.simplyhired.com/search?q=php Showing 1-10 of 144,251 Php jobs

http://www.simplyhired.com/search?q=cobol Showing 1-10 of 130,541 Cobol jobs. COBOL!!! You must also search for go programming language not golang or just go.

http://www.simplyhired.com/search?q=cobol Showing 1-10 of 131,923 Cobol jobs

188k for java and 258k for C++.

Python occupies a niche that isn't going away any time soon: making it easy and natural to write readable, straightforward, more-or-less imperative, slightly boring code of the type you learned in CS 101.

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.

At my work we recently needed to hire a developer. We gave them all a very basic problem to solve and told them "use any language, use any libraries". The idea was to get a feel for their coding style - do they comment their code, is their logic something the rest of the team could follow, will they address unmentioned issues, will they press for clearer requirements, etc.

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.

One of my favorite pieces of code I've written is a 150 line Python script I made to solve a really ugly text processing problem. I have tried to use it as a code sample when talking to potential employers, but it backfires because it makes the original problem look so simple that they wonder why I bothered to send it.

If it's any consolation, Peter Norvig's Sudoku solver seems so readable on the surface that I've fallen into the trap of thinking it looks easy, or that I fully get it. :)

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

Maybe you should try a reverse interview process. Send them the original problem, ask them to have one of their top developers solve it, and then compare solutions.

Is this a real thing ?

It should be.

I once wrote a custom report generator that could pair basically arbitrary input formats (pluggable, I think by the time I was done I'd written importers for CSV, fixed width, and JSON data) and output custom PDF output, with fully-user definable formatting/elements - using XML "templates" just because I didn't want to write a custom parser. Included loops, if statements, etc, and some pretty fancy output features (e.g. output N records per page, with custom sorting, headers/footers/etc). Used ReportLab for the PDF generation. Whole thing was under 1k lines of Python 2.

Why can't Julia fill that role?

Try to do machine learning in Julia; it is difficult. If I want to say fit a gradient boosted tree or SVM its not support in Julia, whilst appears in Python/R libraries. Also, with Spark being more and more popular in the data science landscape, the lack of Julia bindings is also a no for the data scientists I work with (Spark has Python/R bindings).

You will have to reach a little deeper for machine learning methods not supported by Julia. XGBoost has a Julia interface and you can google Julia SVM for myriad of alternatives. Packages like Mocha and MXNet are a few deep learning alternatives. PyCall is also an easy solution for interfacing with Python for things such as pyspark. It also has some of the most convenient to use parallel / distributed computing tools for numerical computing.

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.

If Julia just want to replace Python as the glue interface, it seems to have no chance winning...What it can do, as a glue layer, that Python cannot do?

It's much easier and lower-overhead to call into C, Fortran, and soon even C++, from Julia than it is from Python. If there's a library in Python but not yet in Julia, it's really easy to call into Python from Julia.

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.

Thanks for explaining this.

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.

It's not meant to compete with Python as a glue language. The point is that you can start using Julia right now and be productive by calling other languages' libraries to fill in the holes.

The questions is why would I do that? Because Julia is new?

Well, what do you work on? Julia isn't for everyone.

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.

Lifetime values, customer segmentation, lead scoring, customer life cycles, customer attrition and also quite a bit of reporting. Some text analysis. I use R because it offers superb speed of development, extensive documentation, commercial support and many partner opportunities with the likes of Oracle, Microsoft, Alteryx, Tableau, Tibco and pretty much every analytics vendor. In my experience, R's slowness has been greatly exaggerated.

Yeah, I would use Python for this kind of task, too. Vectorized operations are fast enough in a lot of cases, and the library advantage is important. At this point in time, Julia is a great C/Fortran replacement, but for Python/R/Matlab, it's a trade-off.

Because it's young and we still don't know how it will pan out.

Which role? A general purpose programming language with an emphasis on readability?

Yes...but one that is also very fast, portable and with great generic programming.

I had never considered Julia as a general purpose language. I assumed it was targetted mainly at data science etc.

The core language is general purpose, and IMO really good for high-performance work, but the community is focused on numerical code, so there aren't a lot of libraries for non-numerical/scientific/financial work at this point in time.

Stuff like Numba greatly decreases the need for Julia.

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/

That report is over a year old, which for a 4 year old language is a very long time. The top comment in [1] is from a week ago and highlights why it is now mostly invalid.

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

Interesting stats regarding version 2/3 usage from a moderator of /r/python today:

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%
(Two weeks was ~133 million downloads)


Be aware that PyPI isn't a great way to get accurate statistics. One of the reasons is when tox tests via a matrix, Python 2.7 is usually the first python listed, and if it fails then Python > 3 will not be tested. Also, it'll reuse libraries from the pip download cache.

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 it's important to remember that system-wide packages get installed once, while pypi stuff will get redownloaded a lot. It means that for example users of recent arch, ubuntu and other distros which install python3 by default are more likely to have some of the dependencies already there, while anyone installing just python2 base package will download deps from pypi.

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.

Debian Popcon is interesting too, but don't rely on it either: https://qa.debian.org/popcon-graph.php?packages=python3.4%2C...

    Be aware that PyPI isn't a great way to get accurate statistics. 
You can't just ignore a bunch of statistics because they aren't convenient to you; that's not how maths works.

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?

GP has argued otherwise. PyPI sampling is not random. It is heavily influenced by automatic downloads and such and completely ignores that most simple 2.x libs / non-3.3-tagged libs will work just fine on python 3.

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.

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

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.

I don't believe 2 and 3 are different enough that this theoretical company would turn someone away for being experienced in 3 rather than 2.

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.

It does make you more immediately employable. In sum I agree, but why is the inverse never true? You can learn and use 2, since that is the advantage for employment, then use 3 when you need to just as easily.

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.

4. Some people have made an informed decision and prefer python 2 over python 3, even without considering dependencies/migration cost.

(cue the downvotes)

If you get downvoted for that it's because Python 3 is objectively better than 2 in every way other than the points I listed above...

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

Good support for strings that you want to treat as text but have unknown encoding, the biggest example of which is all OS strings on posix systems. Being forced to treat all strings that aren't guarenteed to be valid unicode as a series of integers makes everything harder - parsing text-based protocols, text-based file formats, hell last I checked it was very non-trivial to write a version of "ls" which didn't crash if the directory contained a file called "\xff".

Massive compatibility with the biggest installed Python codebases?

People already know it?

The most used?

All points I listed above.

And still hugely important.

ekimekim said "even without considering dependencies/migration cost". Let's keep things in context.

    ...it is neither random nor representative of python 3 usage, failing the premise you yourself mentioned.
I'm not arguing the py2 vs py3 band wagon; all I'm saying is that if you choose to dispute the validity of statistics you need to do it properly, not just with 'those stats aren't any good because [arbitrary speculative reason 1] [arbitrary speculative reason 2]'.

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:
Oh what?

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.

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


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

I'm not interested in the health of the python3 ecosystem at all.

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.

In my original reply, I explained why the PyPI statistics are misleading. I then explained to you that there is no easy alternative. The Python interpreter doesn't embed Google Analytics.

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.

As others have mentioned the PyPI statistics aren't random at all. They're a count of downloads based on user agents. The points I mentioned above were discussions I had with the maintainer of PyPI (Donald Stufft) who also recognises that aggregated counts from PyPI are not an effective measure.

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.

I wonder how many users actually download packages, as opposed to something like Anaconda or WinPython. It may be that the users of Python 2 may be more likely to download individual packages because they are creating more specialized installations (e.g., web services etc.) whereas the educational and scientific crowd just get a big distribution like Anaconda or WinPython. For instance I use WinPython for convenience, and typically use Python 3.

To be fair, Python 2.x is installed everywhere and python 3.x wasn't really usable in production until 3.3. And there's barriers to migration like Twisted has.

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.

Er... wait no longer! Grab rakudobrew and perl6 some stuff :)

I'm disinclined to use it, partly because it shows a community that's slow to evolve, but mostly because the Python project decided that 2.7 was the last 2.x.

You're contradicting yourself.

Yes, Python is dying, that's why it just moved up in the Tiobe rankings to #5, displacing PHP (which obviously no one ever uses): http://www.tiobe.com/index.php/content/paperinfo/tpci/index....

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?

I don't see a need for the snark. I don't see this as a troll question at all. Python is obviously thriving for scientific programming but it's not hard to tell that the question being asked is about whether Python is losing popularity as a general purpose web programming language.

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.

Amongst what bubble of people you're entangled with?

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?

Python is dying the same way Apple is dying. Only to people addicted to the new and the exciting.

The snag with that is that once I really digged into them, I found Python (and Ruby) just as exciting as the new stuff (Go, JS on Node). So back I went. Same experience with Apple.

You raise very good points... But the question didn't seem "trolly" to me.

> displacing PHP (which obviously no one ever uses

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

In this case (Wordpress), PHP is used by end users, not by programmers.

Yes, that was a bit of snark, sorry. Was hoping that would emphasize how huge of news it is that Python moved past PHP even on such an arbitrary language benchmark.

The word for Python is mature. If fireworks aren't going off with every release, it's because it's past that phase of life.

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"?

>The word for Python is mature

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

Python is dying because is the freeloader language of choice.

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's maturity is a problem because it provides very little incentive for users to resolve the 2/3 split.

Reading HN, you'd think Java was dying (dead?) too. But it's not. It's an established language with a lot of very senior people still using it. It has it's issues for sure, but it also has a ton of libraries and support.

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

What? The kids? I see young people using python more than any other language by FAR. What region are you? I've seen this through the northeast and midwest United States.

Second this. Python is just the perfect language for concept proving or prototyping.

You haven't tried Scheme.

I don't know it, yet. But I don't know whether it provide the range of libraries Python can provide me with.

If you use Kawa Scheme (http://www.gnu.org/software/kawa) then you get a number of extensions (beyond standards-compliant R7RS), high performance, and access to all the libraries that run on the Java platform.

Java has gotten significantly better in recent years across the board. Python it's a mixed bag due to the 2 to 3 incompatibility transition, one step forward, one step back and some step are changes but not improvements.

Which parts of Python 3 do you regard as being worse than Python 2?

The part where it's not backwards-compatible with Python 2. :)

I know this is not the answer you seek but: adoption. Transition was a blunder reaching Perl proportions.

I don't know. Even though there were and still are problems with Python, especially on the basis of this 2/3 thing, I wouldn't say it feels dead. Well, I mean, of course I do understand that enormous amount of people still use Java, but me personally, since I quit my job as a Java programmer it honestly feels like it doesn't exist. Except for Android it's like there's no real need to use it for anything. Unlike Python, which is pretty much go-to for any scripting and usual CLI tools, go-to for heavily domain-specific stuff, prototyping for any sciency stuff, almost go-to for statistics and ML, still among 3 first choices for web backends. Still new interesting libraries appear which you might want to use. Well, it surely feels like it's still around and relevant when starting something new. Java seems to still be heavily in use because of existing infrastructure (all banks that use Java, that is), not because it has something (maybe even some domain-specific library) which is appealing all by itself.

As a "kid" - you are right !

I like Python, but it's gone downhill.

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.

Shame you started with "Python's little tin god" as it meant I took everything else you said less seriously.

I'm worried about a repeat of the Pascal debacle. Pascal was a good language, invented by Niklaus Wirth. It had some flaws, which were fixable. But Wirth was insistent on not doing anything which would invalidate his elegant, but limited, recursive-descent compiler. He didn't like separate compilation of modules, for example; everything was supposed to be in one big file. He had this thing about conformant-array parameters, where arrays were passed with size info. Strings were limited to 255 characters. The I/O operations all aborted on error. Integers and subranges were designed on the assumption that integers were very big. (The original implementation was for the CDC 6600, with 60-bit integers.) He pushed his version into being an ISO standard.[1]

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

It's a little over the top, but I do agree that python has succeeded despite van Rossum, not because of him.

Python has been the #1 language/technology in Hacker News whoishiring threads 11 of the past 12 months[1]. Seems to be a fine time to invest. (Disclaimer: I publish these trends)

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

I think that says it all. Your HN Hiring Trends site is awesome!

This is an interesting example of what might happen if you think that the things which are the most frequently mentioned on HN are the ones which are the most commonly used in production/industry :)

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

I was taught Java in college and use it at work, but over the years I've done a little BASIC, Perl, Haskell, Lisp, C and C++. All of these languages were interesting and fulfilled specific use cases, but I couldn't see anything distinctive about them. Moreover, there weren't any ah-ha moments...until I learned Python.

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 started using Python because everyone around me was starting to use it about a year ago. By now I'm rather proficient at it and it's replacing my primary language (PHP) to write quick scripts to run from the command line. In a few weeks I'll also be working on a web project in Python (where I'd normally have picked PHP).

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

As a JS developer I think python is strong than ever before , it can use not only in web but also in data analysis. The coming Big Data trend can lead extensive use of python. The LIGO Scientific Collaboration announced that they use python when in their first direct detection of gravitational waves. https://www.reddit.com/r/IAmA/comments/45g8qu/we_are_the_lig... And they are also make some lib of python they used open source in github. https://github.com/ligo-cbc It is excited , isn't it ? Thanks to these news , I have decided to continue learning python since I break it off two years ago.

I've only been using Python for 2 months now. I'm coming from a Ruby, Java, Node background. The things I don't understand about Python and what I miss the most from those other languages is a solid tool chain. From package management down to the test runners. I miss Ruby gems, Bundler, Rack, and Gaurd tools. I miss Maven and the plethora of plugins. I miss NPM.

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.

> Ruby allows for nicer looking code and readability

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):
Compare that to the hideous mess of fizz buzz in Ruby [1] -- there's a lot of magic going on there. Many unfamiliar operators, line #2 is a magic string interpolation thing with tons of weird escaping going on (the #{} seems to be some kind of template which makes stuff inside the "" string actually be interpreted as code which itself contains '' strings, and I don't want to think about the potential injection vectors that could be introduced by this), the ternary operator, absolute value bars, an anonymous function, and defining a function by binding an anonymous function created with -> function call syntax to a name.

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

Here's what your code looks like in Ruby:

  def fizz_buzz(number)                                                                                       
    if number%3 == 0 then                                                                                     
        return "fizz"                                                                                         
    if number%5 == 0 then                                                                                     
        return "buzz"                                                                                         
    return number                                                                                             
  for num in 1.upto(100) do                                                                                   
Don't mistake someone fannying about with code-golfing for the language itself.

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

Python is the least-worst general purpose imperative not-performance-critical OO scripting language. It has lots of problems (weird scoping, community issues, roundabout docs, `''.join()`, crippled lambda, no variable declarations, some lousy naming, module distribution issues, yet more ways to do string formatting, whitespace-sensitive syntax instead of curlies+semis), but the alternatives have worse problems, so Python is at the top of the heap for its type of language.

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.

What's wrong with `''.join()`? It's fine as is, I think, same logic as '{}'.format().

Re. join, I think Perl got that one right: `join(glue, pieces)`.

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

Yes but then you can map things more easily without having to create partials, and it's consistent with how all other methods work in Python (e.g. format method)

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

I've switched to Python a little while ago for the following use-cases, and couldn't be happier:

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

Absolutely not.

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.

It has massive support and libraries for almost anything imaginable. It's not dying. Yes, the transition from 2 to 3 is a bit of a hiccup, but it's going to be around for a long time!

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

TL;DR: No.

Despite some rifts in the community around 2 vs 3 versions, Python is still widely used, no worries.

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.

Agreed. If anything, Python 3 is dying - Python 2 is going strong.

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

Unless there is another language that beats Python in terms of simplicity of toolchain, deployment and syntax, Python is not going to die. Very few people care about the performance of a language (this is same as asking whether Intel i5 or i7 is a better choice when most of what you'll be using is Microsoft Word or PowerPoint), and Python provides reasonable and handy solution to that problem as well (pypy).

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

> Unless there is another language that beats Python in terms of simplicity of toolchain, deployment and syntax

Actually those 3 things are much simpler in Go.

Python2 is not dying, its momentum is the main reason for Python's continued meteoric rise. Python3 is languishing though. At roughly 10% of Python right now but might(?) pick up that slack once Python2 starts to die.

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.


The moment a language is born is the moment it starts dying. No language lasts forever.

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

Python is just a fashion 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.

I do a little work in machine learning (as an undergrad). Deep learning specifically is dominated by Python and C++ (Python for the interface, C++/CUDA for the implementation). Theano's interface is in Python. Caffe has C++, Python, and Matlab interfaces (Python and C++ being the most popular in my experience). Tensorflow has C++ and Python interfaces. ipython notebooks started with Python. The odd one out is Torch; its interface is in Lua.

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.

Python, as a language and a community, seems to focus more on producing code than marketing. This is an observation, not a judgment on Python or other languages.

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

No. Python is extremely useful and will remain so. However Python has fundamental design problems regarding unicode handling and 2/3 discrepancies that make it challenging to work with in a number of contexts.

I agree completely. Python could fix a LOT of that by using the (completely seriously named) https://simonsapin.github.io/wtf-8/ WTF-8 (Wobbly Transformation Format − 8-bit) encoding for it's native Unicode (like) strings.

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.

You mean something like PEP-0383? https://www.python.org/dev/peps/pep-0383/

I'm not quite sure why people are always so concerned about programming languages "dying", like if the language not being popular has anything affect on the applications already using it.

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 think it's HN echo chamber. A lot of articles here about new exciting technologies, but when you look at job postings for example this is not the same song.

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.

Elixir is so interesting (to me) because if a company does adopt it, there's almost no risk. I always view tech from business-tinted glasses. Elixir is a winner from both sides.

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.

yes, but are these articles early sensitive indicators of things to come or just esoteric blovation?

I think they're an indication that people find something interesting, which is often because it's novel.

> Julia for data science

I work in scientific computing, and while me and my colleagues have all experimented with Julia at some level (and definitely welcome having more options), I don't yet know of anyone who has built any part of their permanent toolchain with it yet.

Are there any notable use cases out in the wild yet (known internal use by an organization, or major FOSS tool or framework)?

I won't comment on organizations using Julia, but some conclusions can be drawn from the presenters and sponsors at JuliaCon 2015: http://juliacon.org/2015/

Here is a brief list of some major packages that I am aware of:

- https://github.com/JuliaOpt/JuMP.jl - https://github.com/JuliaOpt/Convex.jl (Stephen Boyd's current and former students) - https://github.com/ApproxFun/ApproxFun.jl (Nick Trefethen's former students) - https://github.com/dmlc/MXNet.jl - http://nemocas.org

Julia has been used (and cited) in at least one Nature publication: http://www.nature.com/nature/journal/v526/n7575/full/nature1...

A larger list (with associated publications): http://julialang.org/publications/

Julia is also being used for courses at a number of universities: http://julialang.org/teaching/

Python is very strong in data analysis, as strong as ever in DevOps, and it's very versatile to always see it show up in other areas.

Most of our Python use is for cross-platform mobile development with Kivy and we're happy with it so far. Certainly happier than having to deal with Java and the disgustingly horrendous Android SDK.

There are a lot of great comments in here already but I'll add my 2c anyhow because it's something I have been thinking a lot about lately.

Python is my absolute favorite language without a doubt.

But Python is dying for ME

I think there is a lot of value in having front and back end code in the same language.

Python is significantly slower than JavaScript and I just don't want to have to run 2x the number of servers to handle the same number of requests.

I host my games on App Engine. Google has no public plans to move Python app engine to Py3. Python 2 EOL is just 5 years away. I move slow - need to start moving now.

-- Also while on the topic, let me just rant about how great the Python Standard Library is and how much I hate NPM and the javaScript ecosystem. I really hate having to evaluate 5 ways of doing every little thing. I wish the node folks would start building a batteries included standard library.

>Python is significantly slower than JavaScript

I don't think there's anything inherent about either language that makes it faster or slower than the other, and it's not really fair to compare one high-performance implementation (Node) with another specific implementation (CPython) when there are other options. For example, have you compared Node vs. PyPy? In my experience they're very close.

Python is dying in much the same way that C is dying, and by that I mean it's not dying at all. I'm no expert on Go or JS but Julia is not even close to being a serious competitor to Python for data science right now. Besides, Julia has a role more similar to R than Python.

I think C and even C++ are basically dead from a job market perspective but seem alive and doing ok in the opensource community. The need for paid C development pales in comparison to the job market for python. The industry, at least outside HN, for "backend" type work has settled on java/.net languages. They are just good enough for 95% of use cases and easy enough to hire for.

AFAIK, for a competitive backend programmers, besides C++/Java, good at least one script language(tool) is a must, let it be bash/perl/Python, etc... More and more people are picking up Python for this role, simply because it is more a complete package than its competitors.

I do agree with you, knowing ONLY Python is not really something to feel good at, but same thing can be said for any other programming language...

Julia for Data Science? Ha!

I think Julia might maybe have a shot at the space Matlab plays in the moment. But I'd define that more as scientific computing than data science.

Does Julia even have a properly supported HBase interface? People are confused about how to connect to SQL Server[1] - until some pretty basic things like that are sorted out I don't think anyone will take it seriously for data science.

Also: http://danluu.com/julialang/

[1] https://groups.google.com/forum/#!topic/julia-users/BOeyuSlz...

Julia is not even at 1.0 yet, and will be full of holes until at least then. It's still a wonderful language for technical/scientific computing, but you don't want it to be your only language if you have to make diverse real things.

Couldn't have said it better myself.

That's almost the complete opposite of Python, which has the ugliness of real world use (eg, 2.7 vs 3), but also has those thousands or real world hardened packages.

Wow, this got more downvoted than I've had in a long time!

I'm pretty sure that this is an uncontroversial view so I'm a little surprised, especially since I work in this field.

Enlighten me, Julia fans?

http://danluu.com/julialang/ is telling but certainly gives little insight whether a statement "Julia for Data Science? Ha!" is justified or wise.

I, for one, look forward to the day I have Python in my frontend.

Browser support for <Script type=text/python>! Viva la revolution!

I would need so much less migraine medicine that the pharma industry would lobby against it.

That day was 15+ yrs ago. Back in the IE4/5 days with ActivePerl and/or ActivePython installed you could do just that (along with VBScript). It also allowed you to use them in ASP pages too.

eg: https://msdn.microsoft.com/en-us/library/ms974552.aspx


Apparently Perl tended to work better than Python though due to not being as picky about whitespace in an HTML script element :)

The thing you ideally want from a language is the ability to benefit from an ecosystem adding functionality, teaching, open sourcing libraries etc.

The Python ecosystem seems healthy to me. Interesting things are happening in the language around incremental typing and async.

Python seems like the language of choice for binding C and C++ libraries.

Python devs seems widely in demand.

There is definitely a pullback in using Python in performance critical conditions where Go seems to be making huge progress.

>There is definitely a pullback in using Python in performance critical conditions where Go seems to be making huge progress.

I work a regular gig, but also have a home business built on Django. I would do it as Dropbox does it- run the company on CPython2.7 and then CPU performance critical services on PyPy. GVR noted they have at least 1 thing running on PyPy.

I wouldn't personally bring another language into the stack unless it's absolutely unavoidable. When starting from scratch, I'd probably still go with Python.

...Or maybe Ruby. I'm starting to see the Ruby guys as being luckier than they think. You can run an entire Ruby shop and transition new services over to the Rubyesque Elixir. Which has significant benefits over anything the Python ecosystem has. I've never used Ruby but may give it another shot, due to Elixir's existence.

Mate, you've got to stop taking the social media hype at face value. I remember desperately trying to learn Haskell during my pedagogical years because all of /r/programming was talking about it. Clearly it was the next big thing! In the end I decided that I enjoyed F# more, but since then neither language has been anywhere close to relevant in my career.

I write my back-ends in JVM languages, because the JVM is performant for my use cases, and the ecosystem is very rich. I'm currently liking Kotlin as a better Java, and I dabble with Clojure for fun. Oh, and I can't resist having a jab at the ol' Go-has-no-generics thing. Go has no generics, which leads to type-unsafe upcasting to interface{} or copy and paste. Both of which are shite.

I write my data science code in Scala (on account of how that's the nicest Spark API, although the Python one looks good).

Yep, JS for the front-end when you're doing heavily dynamic sites, but if it's a slightly-less-than static CRUD site? Django is ideal, free CRUD interface, no fucking around with the tool and fad filled hell-hole of modern JS development.

(I must admit to some hypocrisy because despite the above statement, I quite like React).

No. Python is the third most popular language on Github, for example. Ahead of either Go or Julia.


The Python 2 vs Python 3 debacle has stalled the adoption of new features into Python for quite a while now. Nevertheless, Python has a very nice design at its core. Maybe it doesn't need that many new features.

There are lots of tools and even lots of toolboxes.

What do you like to do? What can you find work for?

If you know other languages, you can shift easily. It's not like you have to invest years into a new language if you're already proficient with others. You're not going to forget if/else logic, what functions do, or object oriented basics. Most languages just have their own syntactic sugar on all of that.

Learn Python.

Learn Node.

Learn Julia.

Be flexible.

COBOL and FORTRAN aren't dead, and you think Python is going to die anytime soon? I don't see it. For the most part, technologies never really "die" per-se.

Now as to the question of what stack to invest in from a career standpoint... my guess is that Python would still give you a very good ROI. Look how popular it is in the machine learning / data science world, for example. I'd bet there will be more jobs for Python coders than for Julia coders for at least another 5 or 10 years or more.

But hey, hedge your bets... invest in something for today like Python, but start spending a few cycles here and there on Julia and Go. Flexibility helps in this field. In my 17 some odd years doing this stuff, I've gone from focusing on C++ to mostly Java, then to Python, back to Java, then on to Groovy, and now am using Java, Groovy and Python. But I'm also spending some time on R, as well as Julia, Go, and Rust, just to stay current.

Python isn't going anywhere. No other language has such a rich set of tools for the complete analytic workflow from data acquisition and transformation, through analysis to end product creation (i.e. web/application development). I think in terms of an exploratory/prototyping language it is going to be at the top of the heap for a long time.

Julia is an extremely interesting language, in some ways it is more "pythonic" than Python (at least in regards to consistency), while also being surprisingly lisp-like. Unfortunately, the library ecosystem is still extremely immature. Within ten or fifteen years, I expect Julia will take over pretty much all of Python's niches.

As for systems/backend code, I'd bet on Scala over go; much more interesting language, and able to leverage the massive java ecosystem.

You think it will take that long?

Julia for data science is not as nearly as true. The landscape of data science or machine learning is shifting so fast because of the recent deep learning revolution, which, IMHO, makes some Julia's featured improvements a little awkward. If it anyway has to delegate the computation to something like GPU, then the goodie Julia has promised, like auto vectorization, are less important.

JS for frontend...Is python ever used in frontend?

Only Go is worthy mention here. Yes, Go has some goodies in terms of performance, so it will eat up some Python's share in server-side programming, which I won't deny.

TL;DR: Python is on rise as the dominant language for data science, which I didn't think any other language can challenge it in short time. It will still be used/favored in light to middle complexity web services depends on tastes.

My suggestion is not to ask not whether your favorite language is dying. Ask why you are so worried about that.

If you plan a career of any length of time technology you will have to up sticks and move to new language countless times. In fact, in some ways doing that is one of your core skills. Embrace it and enjoy it. Perfect your ability to digest and consume a new language complete with its idiomatic quirks and warts and its various ecosystem of tools and frameworks.

In terms of a choice of a language for an actual project, Python is so established that there is basically zero risk in starting a project in Python now. There is exactly zero chance that it's going to be abandoned and you will be left without a viable community of support any time in the next decade. So if Python solves your problem today just use it.

I just got into Python, as a biologist. I'm happy I did it because now the entire large healthcare company I work for (or at least the research department) is switching from Matlab to Python. I have never heard the name Julia before here. Could be because I'm a biologist.

I heard an anecdote from a colleague who was surveying undergraduate CS courses. The prof was explaining what the course was going to be about and said that the students could choose any language they wanted to complete the work something like C or Java or anything didn't have libraries for everything. A student wanted to know if this meant they couldn't use python. Prof said, ya, you probably shouldn't use python for this, too tempting to cheat. Grumbling, so prof asks, how many people actually know C, Java, or something like that? ~50% hands. How many only know Python? ~40% hands. These were CS majors, in an upper level CS course.

Python pretty much replaced Perl in everything yet Perl is alive and well today. So, no.

Some people will always flock to Teh Shiny -- but python isn't going anywhere.

All the interns we've recently interviewed all have Java and Python skills so neither language is dying in any sense of the word. In fact I would probably say that those (plus Javascript) are probably the languages new programmers are learning first.

Both languages are however going through transition periods, with Python the 2.x to 3.x migration is still dragging on and shows no sign of ending. Java is in a period of libraries rebasing themselves around Java 8 and Java 9 will similarly be a disruptive release once project Jigsaw finally lands. But both languages will continue to be around for a long time.

It's merely plateau'd. That's not something that brings news.

If you graph the popularity I would say the derivative gives you newsworthiness (golang, julia) but the integral gives you the popularity.

my point exactly.

I forget where I saw it, but someone said Python is the second-best language for pretty much everything, which is why it's such a useful language to have in your tool chest.

Python is fine. I just came off a job in it and interviewing around saw a couple other jobs in it. I see it competing with Ruby and server-side-js. Python is more mature than either, and has a different flavor that will appeal to some people. Choose your environment to taste. OTOH, job[-2] was switching away from Python due to run speed concerns, towards Go. But while the application would be less Python, the 'devops' system glue would still be all Python.

Python is the new BASIC these days.

Let's look at Julia for example. Its currently gaining steam in numerics, machine learning other technical computing areas...I hypothesize this is compound growth.

For general computing, what would happen when it gains static compilation and can be distributed easily on Linux/Windows, Mobile and then web (with Emscripten/web assembly).

Then its as expressive if not more than python, easy to read/write and faster (unless its written poorly).

It's really easy to get a huge growth rate if you start from a very small number.

No, python's strong. It's just not a fad anymore?

Is PHP still cool? Not really. Yes, there was a day when it was. But guess what: from http://php.net/usage.php PHP: 244M sites, 2.1M IP addresses -- sites powered by PHP.

Python's not going anywhere. It might go out of style, but it's not going out of use.

... they are still trying to replace retiring cobol programmers.

No, it's not dying. It has simply gone enterprise. Which means it is no longer "cool". Python is a good glue language that runs everywhere.

Python is not dying, it's mature and stable.

I play around with NodeJS and front end frameworks like React for my own side projects, but all of my paying client work is made with good ol Django. It just does so many things well and is very mature. I recommend for production code using libraries that have a strong community and have been around for a while so that they don't keep changing all the time.

Don't forget that Django and React make a great combination.

You probably still want Django to handle server-side rendering for most of your site (unless you're a masochist). Django Rest Framework for the API, and React (or whatever) to handle the app-like parts.

This was my original approach. After all, no need to do an SPA for regular pages. Only the app-type parts with a DRF backend and an Angular/React frontend.

But... as I started publishing these apps on mobile app stores (cordova), I found myself also having to write a REST endpoint and client side renderer for the app versions.

Even though I'd much rather do a contact form, for example, in a server side view. But if I also need the REST API and client-rendered version for the app version, I might as well only write it once.

Why not render client-side?

1. On the whole 'normal' websites with an overabundance of client-side rendering are in a kind of 'uncanny valley'. They nearly behave the way a normal server-side rendered site would but something always breaks whether it be the back button or link behaviour, caching/refreshing or something. So from the user's perspective it's often a bit off.

2. It's still more work from the developer's side. You have to implement stuff you get for free with server-side rendering. And currently (and for the foreseeable future IMHO) Python/Django is still simpler, more maintainable and nicer to work with. So I'd prefer to keep the client-side code where it belongs - the parts of the site that are more like an 'app' than a 'website'.

For the past few years, many say java is dead, ruby is dead, nobody want C and etc, still today, individuals and business still continue using those language and invest new framework/plugin/tools for those language. So i pretty sure python is not dead. 'Dead' is for framework when community move from one framework to another.

Over the last year (for the first time) Python surpassed PHP in popularity and seems to be gaining on C#.

Python has never been more alive, IMO.


There's projects where you're trying something new, and there's projects where you're trying to get something done. I recommend keeping the two separate, and for the second type using whatever you feel most productive with. Mixing the two just increases the risk of your project for no real benefit.

I'd say it does well compared to other languages: https://www.google.com/trends/explore#q=python%20tutorial%2C...

In case of Go, it is a dead baby, the language and the tooling suffer from dogmatism and inflexibility. Python is stable and good now, it does not need to change that much. Thus, those who mix up version numbers with stock prices and become happy when they increase switch away and complain. Ignore them.

>the language and the tooling suffer from dogmatism and inflexibility

The inflexibility and dogmatism of the language is its biggest strength, lending it to create universally readable codebases that any Go programmer can pick up and be productive with.

The tooling has never stopped improving, and Go 1.6 is going to make the VENDOREXPERIMENT an official, supported part of the language.

Plus the real reason why backend devs are abandoning Python for Go is a numbers game that Python, short of PyPy pulling a miracle, will never even hope to compete against.

Go tries to make code readable via dumbed down features and arbitrary rules.

The tooling hasn't stopped changing. Improving? Not as sure.

In the last paragraph you compare oranges to apples. Python has never promised to be fast, its promise is convenient use, easy start up and interactive development. Go on the other hand a speed focused thing that gives up developers' comfort for dogma and modern features for ease of development of the compiler.

Don't forget that dumbed down features and arbitrary rules were what made Java popular.

For the frontend, and asynchronous server backend (Node), JS won hands round. I don't see Python getting there.

More systems and backend use Python (including at Google) than Go.

An insignificant amount of people use (or will use in the next 5 years) Julia for data science. Python (and R, Matlab) rule there almost completely.

I don't think so, it seems to be the go-to language for scientific stats work, maybe for web development it is trending down though?

Udacity's stats courses use R and Python, a friend of mine who works in environmental research, it is all they use! Google still use it heavily as far as I know?

Python was never a front end language, and it was never a systems/backend language, at least not a good one. Its main strength is that "batteries are included" and you can get something usable going really quickly. None of these purported challengers has that strength.

Quite contrarily, I've seen an increasing amount of Python usage in enterprise software, especially analytics applications. More and more job postings are starting to mention Python, and the web frameworks associated with it (Django, Flask, etc.) are more popular than ever.

Believe it or not COBOL is still a thing. So it is doubtful Python will ever die die. At least not for a very long time. But, and I think this answer is probably more to the real spirit of your question, one could reasonably argue that Python has reached it's peak.


Python is 5th place after the three C's and one J.

You might want to check [This].(http://www.itjobswatch.co.uk/jobs/uk/python.do) It doesn't look like dying to me.

First there was Perl. Now there's Python. Until there's another powerful scripting language that starts with a P, I think Python is going to be safe. That being said, rumor is that Perl is back on the rise...

Not in my sphere of activity. I have a friend who recently started his PhD... and is moving all of his development from C/C++/Fortran to Python. Numerical code even - he just doesn't want to bother.

Citing this example isn't very convincing.

Would be more interesting to know what language he uses when he finishes his Ph.D.

Well, I also have two other colleagues who started using it some months ago to parse data. They don't know about Go or Julia. I think the "wow" factor of Python might be lower than it used to be, but it's not considered dead, at least not in science. Does that reflect the broader reality? I don't know :)

No, it's just pining for the fjords.

People still use Perl and Tcl and Cobol. You'll be fine with Python if it's a good fit for what you're doing. It's a solid language with a solid community.

Python is used in academia (eg SICP) so it's not going anywhere. Consider it's a google approved language like Java and Go and Javascript. I can't see python going anywhere.

Python has always been under attack because people using it are busy making things instead of wasting time with language debates.

Just because Python doesn't have zealots doesn't men its dying.

I'm a guy who has funded a bunch of tcl development. You think python is dead? Wow. Python seems pretty alive to me.

Julia? Now you're just making me laugh. Julia has a lot of potential but won't even begin to scratch Python for about 5 more years. Scientific programming is very very addicted to its tools. There is a reason even SciPy (for Python) is compiled Fortan (yes Fortan!) code. R is king for data science and the only reason it lost ground to Python is that R is a one trick pony compared to jack of all trades Python.

It's called the Lindy Effect:


Python (and Fortran), having survived this long, seem destined to live a lot longer than the challengers.

Noooo freebsd and Python are dying , zombie-Linux-Javascript-Jesus will save us with docker on mint .

Django, Flask, PySpark, tons of solid GIS stuff, IPython Notebook, Ansible, etc. etc. So no.

Yes. Join the club.

Sincerely, Perl Programmers :)

The practicality of Python will keep it around for the foreseeable future

I don't know. As a single developer house, I have a behemoth of a project.

Started out with PHP, then used Python for the backend (php sucks as daemons). Expanded to NodeJS for real-time elements. Used JS exclusively for the front-end. When I found python not working as it should be for heavy concurrent tasks, I used Go.

So PHP, Python, NodeJS, Go, JS all for 1 project. Couple this with NoSQL, Postgres, Varnish, Nginx and being a linux sys-admin and throw in clustering, security and a whole lot of other things. Wow, something has to give.

4 months ago decided to learn Go. Now I'm almost at the point where I have a JS front-end and Go backend.

I regularly see complaints about Go having issues. I don't see this as the case. I went from PHP/Codeigniter MVC backend including sessions, validation, integration with nodejs using historyJS and a small JS footprint for the front-end SPA...

To a couple of days worth of work which involved grabbing GIN (the framework), make it do MVC, put in JWT, use GIN for validation and Gorilla/websockets for real-time.

There are many blogs, code samples on github, for a lot of different use-cases or to get the gist of how something is supposed to work. I havent yet found myself not being able to do what I need with Go.

I think what is the sticking point. A lot of developers want to import packages and just build the core of their app. I don't know. I find myself WANTING to build everything out because then I can trust that it will work and work in production. So if a library isn't available. Fine, I'll just build my own.

In fact, the net benefit for me, was that I no longer need to think about scaling my entire application. I made every facet of my old application into micro services that can now be clustered. In addition, the overhead for running Go is now very minimal. The outlay of $$$ each month dramatically went down vs running PHP/Python.

Finally yes, I understand that if I wanted to double down with Python or NodeJS, I could have probably achieved the same result. I'm sure someone will reply saying, why didn't you use X or why didn't you use Y. The fact is, I used Go. The barrier to entry to learn it was minimal to none. I hit the ground running with Go on day 3. Go has paid back lots of dividends and it continues to do so. All my new development is with Go and I don't miss any of the other languages and not only that, upgrading from 1.4 to 1.6 hasn't bothered me in the slightest. I hope that trend continues with 1.7 and 1.8 and beyond. Oh and getting http2, better GC and other goodies to boot. May that trend also continue.

I think in the next 5 years, things will be different. I think if Go starts to match the number of libraries Python has, it will be different. At this point, yes, Python may well be dying.

I completely agree with you and I had the same experience. Once you know the Go concepts (which are very few and simple) Go is not harder to write than Python. Probably easier to write and read.

I came to the conclusion that people who complain about Go haven't really try it.

No. Python is rather getting stronger and going enterprise than dying

If anything, it is growing. Large companies are now adopting Python.

If people still use PHP I'm sure Python will be fine.

How is Python doing as a replacement for Bash scripting?

>>> Is Python dying?


It is dying

No we use python a lot, we are a python shop

I love Python and the community behind it.

Netcraft confirms it

Go doesn't have anywhere near the amount of libraries or support that we see with Python.

Python isn't being assaulted on any front. We have always had multiple programming languages and some are better than others.

My issue is that we seem to have these fad languages, like Ruby-on-rails. I still remember when it was rammed down our throats on HN around ~2008 and you were instantly down voted if you wanted to objectively talk about it's pros and cons.

Now, all of the same people from that community (which I noticed, are mostly designers, not developers) have jumped ship and moved into Javascript frameworks like Ember.js and node.js.

PHP, while flawed and not cool anymore, is still one of the most popular languages.

Python will be around for a long time.

I'd say PHP is still cool, there's nothing quite like it. (For good reason, according to snooty devs, who are the ones that don't think it's cool or ever was cool...) I'm probably closer to a snooty dev myself now too with my favorite languages to sip on being Clojure/Lisp/Python2.7/Nim, but man PHP was the most awesome thing when I was 15-16 and learning web programming. I still find aspects of it cool when I do web stuff in other languages (though a lot of that is probably from the CGI model), and there's no way it can maintain its 80% market share if no one (even out of ignorance) thinks it's cool.

When people ask if Python is dying on the web... seems kind of irrelevant, it never had much market share there anyway. Python's strength is in its breadth, with a few deep anchors here and there. I agree it's not going anywhere.

> Go for systems and backend

Certain sorts of systems and certain sorts of backends maybe. There is a reason people prefer dynamic languages for web based backends for example - the amount of text mangling and arbitrary data structure manipulation becomes a serious headache in a compiled language, be it Go, C/C++ or what-have-you.

I work on a large system written entirely in Python -we've considered introducing Go to speed up certain processes, but Python will remain the foundation for the foreseeable future.

>I work on a large system written entirely in Python -we've considered introducing Go to speed up certain processes, but Python will remain the foundation for the foreseeable future.

Consider doing what Dropbox does, use PyPy for those few processes that need more CPU performance. They run 2.7 for most things and PyPy where they need to.

The code written to control the LIGO detectors was all python.

"What language will replace python?"


Don't trust any of the statements here. People are just responding with qualitative predictions and observations of the tiny little programming microcosms they dwell in.

No one here can produce an accurate prediction of the stock market anymore than they can predict the future of python. The thing with stocks though is at the very least they can look at a pricing trend line. People responding to you here aren't even looking at any quantitative data.

See the data here:


Is python dying?

The data says "Maybe?"

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact