Ask HN: Is Python dying?
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?
368 comments
[ 4.8 ms ] story [ 273 ms ] threadPython 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.
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.
A tad bit old, but read this: http://www.curiousefficiency.org/posts/2012/10/pythons-futur...
TL;DR: No.
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?
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.
(see also next year will be the year of Linux on Desktop)
I think that the reality of modern scala is that, while there is in no way a unified use of the language, the way to use Scala is in its own, intermediate location. Libraries have big gains from the most exotic features that make it be closer to FP, like higher kinded types. while business code tends to look more like java with case classes and algebraic data types. The difficult part is the fuzzy middle.
Another important part of adoption is that Scala's strengths lie in a few good libraries that underpin some great use cases. For instance, using Scalding or Spark as ways to do big data, or building other kinds of distributed systems on top of Akka. For other uses, like writing simple CRUD services, there are many options, and almost all of them are bad, which is why treating the language as just a better Java just doesn't fly.
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
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.
http://elixir-lang.org/
And yes, it's quite fun (and mind-bending at the same time, in a good way).
/s
Disclaimer: complete Elixir noob
But those that read my Java, C# and C++14 code, better know their way around lambda calculus.
Or maybe that's just wishful thinking. I just want it to be so.
https://fosdem.org/2016/schedule/event/fat_python/
A pity that they did not seem to handle the business side of things well, and went down and were bought. (I'm sure there were external factors too, don't mean to say it was partly or wholly their fault. Just don't know.) Don't know much details on exactly why that happened, though I did read about it now and then, and follow Jonathan Schwartz's (last CEO of Sun) blog for a while.
Another change that broke significant amounts of code would just make things even worse.
My objection to 3 was it did nothing for me. All I got out of it was work dumped in my lap just so my code would continue running.
Giving us a GIL-less pypy with jvm-scale performance would be worth a lot of hassle.
worth a lot of hassle to you. I imagine there are people who wouldn't find it worth the hassle. e.g. people who use python as a glue language where it's not close to being near the performance bottleneck - breaking the language to make it 'faster' would do nothing for them.
And yes, I'm talking broadly about the rise of FP.
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?
While most of your examples are valid, I don't think Haskell is remotely object oriented. Type classes are not classes.
Quoting myself
> ... support polymorphism and extensibility.
OOP isn't only the C# and Java view of the world.
I realise people disagree about what exactly should be considered OOP, but personally I think not including inheritance in the definition broadens the term beyond usefulness.
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.
My thinking is that if you are so popular you can afford maybe to start 20 more 5$ instances. And really I find it hard to think of problems that cannot be solved with 20 x 5$ DO VMs at least in Java.
Writing multi-pthreaded Java apps is not my idea of a good time. I am very interested in Elixir, but at the same time recognize that in reality I use Python. And if folks want to knock themselves out writing multithreaded Java apps... to go use Java.
I think the Node model for most, if not almost everything, fits needs well with its single-threaded event loop and scaling by process. Explicitly spinning up pthreads should be reserved for systems-programming, and in which case you are probably going to be using C(++)/Rust(?).
>You'd think everybody is suddenly working with realtime stream analysis on huge datasets and are battling millions of concurrent users these days.
I almost want to archive this somewhere or put it on a plaque next to my desk.
http://gamasutra.com/view/news/169296/Indepth_Functional_pro...
"My pragmatic summary: A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention. Programming in a functional style makes the state presented to your code explicit, which makes it much easier to reason about, and, in a completely pure system, makes thread race conditions impossible."
Functional paradigms/languages, and immutable values, and controlling side effects, greatly help with that, in my front-line coding experience. Therefore, I am a fan.
Do you enjoy doing needless extra work? In other words, are you a little bit lazy? (in the Larry Wall "laziness/impatience/hubris" sense). If so, you should be at least trying out functional paradigms and see if they work for you like they have for pretty much everyone else who has taken them on.
But suggesting we need to start from scratch with new untested 3rd party libraries(that other people take for granted) and rewriting some of them. Even the simpler stuff like suffering the quirks of the extra tooling(build tools, IDEs) for a new language and all because of the death and doom we are supposedly seeing today(which I dont and I've yet to see people doing nightly restarts of web servers for some years). Unless you do consultancy for that language(or are seeking employment in a niche market) I think it's a little mad.
For me to declare the defeat of OOP and win of a FP language I first need to hear the voice of people having to do maintenance work on legacy code in that language as I'm too old to only believe there is such a thing as panaceea or there are only upsides to an alternative.
https://en.wikipedia.org/wiki/John_Backus
Not taking any sides in this beef, though, just an interested bystander.
A subset may be.
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.
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.
There's a lot more competition for computer languages. It might end up like Perl. More people use Perl today than 15 years ago but its importance has waned.
You really haven't addressed the issue. You simply did that dance that developers do when debating a topic. e.g. "This one is too new..." I remember when the iPhone was released, that similar misguided logic was used. Microsoft owns 20% market share and Blackberry is huge. Android was junk in its first couple of releases. Now they rule the world.
Languages like Python will have a problem because Swift and Go, for example, provide performance and type inferencing. They both just need lots of 3rd party packages. Something like a well-done cross platform F# could also prove popular. Higher level programming means safer code.
- given I have a problem, how likely is it that it's a problem in the runtime nobody saw before?
- given I want to do X, how likely is it that there's a library doing it already present? (and how likely that there's one established library rather than 10 trivial attempts?)
- if I can't find a solution to X, how likely is it that there's a solution in the first link on google? (and how likely is it that it still applies to current version?)
These have everything to do with the maturity and popularity of a language.
The iPhone / Android move is exactly what I meant about predicting popularity being like stockmarket. You've got as much information as the next person normally. If you believe the logic was misguided and you knew better, I assume you made lots of money as one of the first people to invest in the right ecosystem, right? Unless you have the weight to move the whole ecosystem, you can just choose the right solution for yourself - and most of the time it's going to depend on popularity.
Scala, F#, Kotlin, OOC, Swift, C#, OCaml have performance and type inference, and that's just some more popular ones. Python didn't have a problem because of them. (and 3 of them have a massive amount of libraries ready to be used)
Once again, you're doing that dance. Do you think I'm learning anything here? Watch out for Go and Swift. These statically typed languages are better for large projects.
Please skip the part where you explain Python's optional typing.
>Why do more people use Python over Perl?
Two factors, it came packaged by default on Linux distros and OSX. That was really a king maker in itself. Then add that the language itself is that much better in most people's eyes. People don't really like obfuscated code unless it's the only game in town (ie. the 1990's and Perl).
>Watch out for Go and Swift. These statically typed languages are better for large projects.
It will be interesting. But both have pretty big flaws so any extraordinary claims will demand extraordinary evidence of success. Neither language has exceptions. Go is controversial in its conservatism and this is likely due to the fact the entire team had to agree to add features to it. So it did end up odd in some ways because of that. Swift is in a constant state of change. Both are missing a lot of libraries. I've tried to use Go and see many abandoned projects like Martini and newer projects seemingly abandoned like Revel. The Go faithful will tell you this is because frameworks are not The Go Way, and point you to the Gorilla toolkit instead. I'm not sure I buy that story unquestioned, or not. On the whole, I'm unconvinced due to their language characteristics, that Go or Swift are ideal replacements for either Python or Ruby for webapps.
>These statically typed languages are better for large projects.
Yes, but I wouldn't want to write poorly engineered, bloated and difficult to port code even with static typing. I don't write massive 500KLOC projects so it's not a problem for me, but I have a policy of modularization with my code that would stem the issue (regardless of static typing or not). When you get to 500KLOC, there is no magic fix. Static typing, modularized code, nothing is a cure and hardly even a band-aid.
As a result of all this, I'm still onboard the Python train. I honestly do not see myself hopping off with PyPy being here today and Pyjion, Nuitka, and Pyston all up and coming. I would not be discouraged if a Rubyist either.
Of particular interest is that Microsoft is working on Pyjion and if it works out, API changes will be made to so that you download a module and JIT right from CPython3.
I'm probably more interested in Rust over Go and Swift at this point. Go is an island, similar to Java that way and not C ABI compatible, this makes it a less than ideal wholesale replacement of Python or Ruby. Swift is just too young on both the server and iOS. Rust itself is the best language I will likely never need to use, but its existence unlike most languages, makes an enormous amount of sense.
As for Python: I think it is starting to grow again in the Linux world.
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.
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. :)
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).
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.
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.
C++17 also feels surprisingly dynamic, and together with Cython for easy Python-C++ interop also decreases the need for Julia.
And reports from the Julia world are not exactly encouraging - http://danluu.com/julialang/
[1] https://news.ycombinator.com/item?id=11070764
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.
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.
What you can do in Julia that you can't do in Python is write high-performance library code in the high level language. If you need to write custom code that isn't just using stock numpy or scipy algorithms right out of the box, and needs to use custom data structures and user-defined types, Julia is a fantastic choice. You can try with Cython or Numba or PyPy, but you're either working with a limited subset of the language, or forgoing compatibility with most of the libraries that people use Python for.
Julia feels like writing Python but does not allow some of the semantically impossible-to-optimize behaviors that you can find in Python, and has a type system that you can use to your advantage in designing optimized data structures for the problem at hand.
As to my own experience dealing with data, the degree of freedom, as basically a programmer, is small. Specifically, I have to think and bear tools in my mind from the start. Which might not be ideal, but cant avoid anyway.
A few notable solutions: 1) The C guy. Damn if he didn't blow that problem out of the water. I never want to be responsible for anything he coded. Entirely too complex, no comments, lord knows what side effects he put in place.
2) The java girl. Didn't finish. Didn't do any logging. Very logical separation of code. Lots of comments. Had to continually reference a text file in order to run the command to show output.
3) The .net guy who attacked the problem with Python. Imported a handful of libraries. Wrote 14 or 16 lines of code. Completely baffled that we would provide such an easy problem. When asked why he didn't use his strongest language, he laughed.
One of them got hired and won't have to write a single line of .net anything for a very long time.
0: http://norvig.com/sudoku.html
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.
While Python may be 'under assault' from a conceptual point of view, the job market would beg to differ!
* I've seen more C++/Java/C# than anything else, with a large legacy base of COBOL/RPG (yes, GMI, we're looking at you...).
* Industrial-grade quant libs (for risk, P&L, models that need regulatory approval) tend to be in C++, with the infrastructure to run them increasingly in Java.
* Lots of VBA on the desktop. Every department runs on Excel...
* Python is making inroads (see Quartz at BofA, Athena at JPM), but I suspect that it's still vastly outnumbered (by whatever measure) by C++/Java.
Some firms (and departments in bigger shops) embrace new technology agressively - at my firm I know of large Scala projects, python, big data (mainly Mongo/Hadoop), R and some Haskell.
That said, on my first job in the UK for a large insurance firm, we employed a team that wrote custom CICS machine code for Z-series mainframes. Beat that with yer fancy functional languages...
So no, I wouldn't say that python is dominant.
Where do I fit it?
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.
Which is why numpy and scipy are so full-featured and pretty damn fast.
To say NumPy or SciPy is just the sum of the libraries it uses is a bit like calling MATLAB a fancy interface for LAPACK. That really was what MATLAB was intended to be originally, but to reduce it to that is missing the appeal. As somebody who absolutely loathes MATLAB, even I wouldn't think that is fair.
The major feature of Python for me is that all its various open source modules for anything n-dimensional (matrices, image processing, GIS, machine learning, etc etc) all use the same data structure: the Numpy array. It's basically part of the standard library that is developed outside of it for pragmatic reasons. And with the speed of Fortran array operations.
That's something that only Matlab really has as well, but Python is much better in other aspects.
This means Python and Ruby aren't as much of a first choice as they used to be, even if they're arguably a lot faster for getting MVPs out.
Which is precisely why all of my new code targets Python 3 and I use PEP 484, and before that I always had type information in my docstrings. There's some places where duck-typing makes sense, but a lot of times I'm really just doing things like I would in a statically typed language so I just type the crap out of everything and run MyPy against it.
Unfortunately the runtime itself doesn't benefit at all from the type information, but I know I any of my .Net-centric colleagues can easily inherit any of the Python code I've written and be able to read it without much headache - without having to intuit what magic goes on behind the scenes, especially with things like the Pyramid request/context objects.
Just use Arrow http://crsmithdev.com/arrow/ everywhere, all the time(s). Now your date/time problems are solved.
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.
Here's the breakdown by which Pythons were used to download from PyPI in the last two weeks:
(Two weeks was ~133 million downloads)https://www.reddit.com/r/Python/comments/45sm94/what_are_the...
I don't doubt that python 2.7 accounts for the majority of the downloads, but I sincerely doubt 2.7 usage is at ~85%.
2.6 usage is probably almost exclusively RHEL/CentOS 5/6 system pythons and not representative of actual projects.
Also pip itself got upgraded to use caching by default not that long ago. All distributions defaulting to python2 will still have old pip which redownloads your packages on every installation (`tox -r` for example). More recent distros will give you tox which caches the downloads locally (which lowers the numbers).
Pypi also doesn't count private repos. If openstack started testing commits using pypi repository and turned off caching, I'm guessing it would add at least 10% to python 3.4.
TL;DR: pypi stats are interesting, but don't rely on them to give you precise answer.
Statistical sampling is based on the premise that your sample is randomized from the total population; I would argue that the stats from pypi represent a reasonable random sample of python users around the world.
Certainly, you can argue otherwise... if you care to provide some meaningful alternative statistics?
In other words, it is neither random nor representative of python 3 usage, failing the premise you yourself mentioned.
There's no easy way to determine Python 3 usage overall. Your best bet is to go around polling companies of all sizes as well as indie devs. What you will find is that:
1. Some amount of people still use Python 2.x because they don't know any better
2. Some amount of people want to use 3.x, but still use Python 2.x because of incompatible dependencies.
3. Some amount of people (companies mostly) still use Python 2.x because a migration to 3.x is currently too costly.
1 -> This is partly caused by FUD. Hating on Python 3 has become a popular past time of people who don't know how to be productive otherwise. It's also caused by the very high amount of tutorials etc around the web that "require" 2.x because, for example, they have an unparenthesized print call (relevant XKCD: 353). Arguably this is one of the big failures of the 3.x push.
2 -> That number is constantly diminishing as more dependencies become available on 3.x. The most recent big win is Scrapy, a massively popular scraping framework, which just finished its 3.x port a couple weeks ago. It's an ongoing process - we are in a much better state than we used to be, the Py3WOS is looking almost entirely green.
3 -> This number is mostly irrelevant as it tends to be in closed ecosystems. So maybe CloudShareBuzzr Inc. is using Python 2.7 internally, but they don't produce anything open source so it doesn't affect the rest of the ecosystem. As new, major features are constantly added to Python 3.x (venv in 3.3, pip in 3.4, async def in 3.5), eventually the cost of switching will be worth it.
Can you actually justify these assertions?
Or are you just speculating because you don't like the results?
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.
Yes:
- It has been done before
- I've been around the Python ecosystem a long time and I know a lot of its users (a random sample, if you will)
- I spent several years freelancing as a Python dev which gave me the occasion to do exactly that. While that is not a representative sample on its own, my data matches up with the rest.
But all things aside, you really need to check your damn attitude at the door. I neither like nor dislike the results. The facts that matter are that Python 3 has a great ecosystem today and that is what matters to me; not whether my neighbour uses Python 1, 2, 3 or PHP.
My only point is, was and remains, that statistics are more complicated than simply 'those statistics do not match my personal perception of things'; justify your argument with actual data.
I'd would be interested to see any alternative stats on the subject you care to link to.
What you're left with is polling, and I gave you insight (backed with my own experience which, yes, is actual data) into what you might find if you went that route. I have no actual numbers on such polling because my samples are too small to be useful. All samples are too small to be useful at this point.
The reason I brought up the health of the ecosystem is because you seem to think I'm biased, or lying, or maybe I'm just a bad person and like one version more than the other. I was just trying to remind you that it's a language version, not a presidential candidate.
(cue the downvotes)
Seriously. List one feature Python 2 has that Python 3 doesn't?
People already know it?
The most used?
It does matter because that means if you ever want to do it as a job, you HAVE to learn Python2 for that gig at CloudShareBuzzr. Paying your bills is always going to top using "the latest version" of anything. I'm not sure why people ignore or miss that point.
Python3 is the optional language, 2 is mandatory if you want to get paid.
Learn that print doesn't need parens anymore, a few renamed modules, that Python 2 str is mostly equivalent to Python 3 bytes and Python 2 unicode is mostly equivalent to Python 3 str and you're most of the way there.
Let the tech live or die based on its actual merits (employment, technical etc), not trying to get more people onboard with propaganda. Considering the money is with 2, I think what you said backs it up even more. 3 will be easy to pickup when needed.
There are no good stats that give an accurate representation about usage % of each python version. PyPI is the only proxy we have, and that is skewed by a number of factors (two of which I mentioned). The overall trend is probably accurate, but exact percentages certainly are not.
My like or dislike for python 2 or 3 has nothing to do with my comment upthread. I was simply stating a number of facts about the data that people can take or leave as they like. It was not "convenient" for me to share those facts. I simply thought people might want to be aware that there's nothing scientific about the aggregated percentages.
It's been a lot of years, but people are slowly and finally starting to migrate to 3.
It could be worse. I'm still waiting for perl6 because those guys got caught up in Haskell hell.
I'm very excited about Elixir for example. There is a new Elixir blog post/article/github repo posted on HN every day, you would think that Elixir is the new cool thing. Well, not easy to find companies that actually use it.
It's built on technology older than Java. I'm not sure most people need what it offers immediately, but it's certainly a safer bet than most new things. Including CPython3 and Perl6.
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.
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'.
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.
Python was doing just fine until Python's little tin god came up with Python 3 and tried to drive a stake through the heart of Python 2. That backfired, badly; six years on, Python 2 still has far more production use than Python 3. (No, it's not about Unicode. Python 2.6 and later do Unicode just fine. I've written sizeable all-Unicode systems in Python 2.6. It's just that in 3.x, it's the default.)
Coming up next, Python 4, with typing syntax that isn't checked. Ugly typing syntax - some in comments, some as annotations. There's an argument for optional type declarations that are checked, but unchecked declarations are trouble waiting to happen.
The PyPy crowd has brought off a miracle - an optimizing compiler for Python that supports almost all the dynamism of CPython. It took a long time, but they did it. CPython should be retired now, or made to conform to PyPy. But no; the little tin god insists that his CPython defines the language. The PyPy developers struggle to keep up.
The language isn't the worst problem. It's the wildly variable quality of the libraries. The great thing about Go is that it has libraries which are used internally by Google, and thus have been executed billions of times. Python's PyPi (formerly Cheese Shop) has no quality control, and many versions of very similar libraries, each with different bugs. There's no convergence.
ISO Standard Pascal is useful mostly as a teaching language. You can't do much real work in it. So Pascal fragmented, badly. There were lots of incompatible variations. In time, Pascal was abandoned.
Sometimes the original language guru has to be pushed aside before they run the language into the ground.
[1] http://www.pascal-central.com/docs/iso7185.pdf
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).
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
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...
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 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.
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.
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 :)
Is this really the case?
https://github.com/niner/Inline-Perl5
http://stackoverflow.com/questions/9173043/how-can-i-use-per...
My understanding is that LOTS of Python2 programs work fine in Python3 with no (or very trivial) changes. Very very few Perl5 programs will work fine in Perl6 with no changes.
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.
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.
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 came to the conclusion that people who complain about Go haven't really try it.
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.
My opinion: Python will outlive the three languages you list. But it's dying outside data science, and maybe even there. Optional typing can't compete with modern type inference, and there is too much dynamism in the existing Python ecosystem (even though it's so rarely used - there's not a monkeypatch culture like in Ruby - it's used often enough that you can't just remove it). But not today, probably not in five years either. In fact with the community finally having rallied around 3.x this is probably the best moment in years to leap into Python.
But yeah, all languages are dying, some faster than others. You have to make your own judgements, and learn general skills so that you're not bound to one particular language (unless you're very confident in that one language).
If you want truly survivor languages look at Smalltalk. More than 30 years and still alive. Is not about modern type inference or dynamism... it's always about the people. And people in Python doesn't have that commitment with the technology, they are more like freeloaders.
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.
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.
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).