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?
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.
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.
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.
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.
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.
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/
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.
Here's the breakdown by which Pythons were used to download from PyPI in the last two weeks:
2.7 85.90%
2.6 6.66%
3.4 4.64%
3.5 2.09%
3.3 0.56%
3.2 0.12%
https://www.reddit.com/r/Python/comments/45sm94/what_are_the...
I don't doubt that python 2.7 accounts for the majority of the downloads, but I sincerely doubt 2.7 usage is at ~85%.
2.6 usage is probably almost exclusively RHEL/CentOS 5/6 system pythons and not representative of actual projects.
Also pip itself got upgraded to use caching by default not that long ago. All distributions defaulting to python2 will still have old pip which redownloads your packages on every installation (`tox -r` for example). More recent distros will give you tox which caches the downloads locally (which lowers the numbers).
Pypi also doesn't count private repos. If openstack started testing commits using pypi repository and turned off caching, I'm guessing it would add at least 10% to python 3.4.
TL;DR: pypi stats are interesting, but don't rely on them to give you precise answer.
Be aware that PyPI isn't a great way to get accurate statistics.
Statistical sampling is based on the premise that your sample is randomized from the total population; I would argue that the stats from pypi represent a reasonable random sample of python users around the world.
Certainly, you can argue otherwise... if you care to provide some meaningful alternative statistics?
In other words, it is neither random nor representative of python 3 usage, failing the premise you yourself mentioned.
There's no easy way to determine Python 3 usage overall. Your best bet is to go around polling companies of all sizes as well as indie devs. What you will find is that:
1. Some amount of people still use Python 2.x because they don't know any better
2. Some amount of people want to use 3.x, but still use Python 2.x because of incompatible dependencies.
3. Some amount of people (companies mostly) still use Python 2.x because a migration to 3.x is currently too costly.
1 -> This is partly caused by FUD. Hating on Python 3 has become a popular past time of people who don't know how to be productive otherwise. It's also caused by the very high amount of tutorials etc around the web that "require" 2.x because, for example, they have an unparenthesized print call (relevant XKCD: 353). Arguably this is one of the big failures of the 3.x push.
2 -> That number is constantly diminishing as more dependencies become available on 3.x. The most recent big win is Scrapy, a massively popular scraping framework, which just finished its 3.x port a couple weeks ago. It's an ongoing process - we are in a much better state than we used to be, the Py3WOS is looking almost entirely green.
3 -> This number is mostly irrelevant as it tends to be in closed ecosystems. So maybe CloudShareBuzzr Inc. is using Python 2.7 internally, but they don't produce anything open source so it doesn't affect the rest of the ecosystem. As new, major features are constantly added to Python 3.x (venv in 3.3, pip in 3.4, async def in 3.5), eventually the cost of switching will be worth it.
...it is neither random nor representative of python 3 usage, failing the premise you yourself mentioned.
Can you actually justify these assertions?
Or are you just speculating because you don't like the results?
Your best bet is to go around polling companies of all sizes as well as indie devs.
What you will find is that:
Come on. Now I can't take you seriously at all.
You know what they're going to say already, without even asking?
You're just speculating.
Stats > guesses.
Even if the pypi stats aren't completely reflective of the entire ecosystem, I'm going to argue that they give a pretty decent impression of it, regardless of the mild bias that you've listed above but can't quantify.
Yes:
- It has been done before
- I've been around the Python ecosystem a long time and I know a lot of its users (a random sample, if you will)
- I spent several years freelancing as a Python dev which gave me the occasion to do exactly that. While that is not a representative sample on its own, my data matches up with the rest.
But all things aside, you really need to check your damn attitude at the door. I neither like nor dislike the results. The facts that matter are that Python 3 has a great ecosystem today and that is what matters to me; not whether my neighbour uses Python 1, 2, 3 or PHP.
My only point is, was and remains, that statistics are more complicated than simply 'those statistics do not match my personal perception of things'; justify your argument with actual data.
I'd would be interested to see any alternative stats on the subject you care to link to.
What you're left with is polling, and I gave you insight (backed with my own experience which, yes, is actual data) into what you might find if you went that route. I have no actual numbers on such polling because my samples are too small to be useful. All samples are too small to be useful at this point.
The reason I brought up the health of the ecosystem is because you seem to think I'm biased, or lying, or maybe I'm just a bad person and like one version more than the other. I was just trying to remind you that it's a language version, not a presidential candidate.
(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.
It's dominance of science is why Python has 25% science talks this year at PyCon, and why we see articles like: http://www.infoworld.com/article/3012442/application-develop...
But yes, if you didn't know any languages, then of course you should invest in an immature language with no mature libraries for the tasks you need to complete, because you were given a few months of extra runway time by your boss to fill-in the library ecosystem instead of getting your job done. We'll ignore that PyPy places you damn close to Go in terms of performance (except with mature proven libs), and that usually your task won't be CPU-bound anyways (the GIL release on I/O tasks)....
Why do troll questions like this even hit the front page of HN?
If someone wanted to get into building web apps would Python be a good choice?
The answer is likely to be colored by your experience. I'd say yes, it is losing ground to other languages in the context of programming for the web. The people who use it know why they're using it. Othetwise you don't see many coding boot camps teaching Python. It's all about Ruby and Node.
But is Python dying? Not by a long shot. It's just getting less attention right now because of some of the other new toys that are making a lot of noise right now.
I consider this a troll question because frequently I see HN questions like this completely disconnected from programming communities at large (which do not participate in HN), extrapolated to the wider web of all programmers. By this factor alone I'd expect Java to be completely obsolete by now.... but obviously no one is oblivious enough to reality to suggest that.
As for that question, if you want to build webapps right now, then yes, Python, as well as Ruby, and PHP, would be absolutely fantastic choices. The library ecosystems for all three of these are incredibly rich, mature, and well supported. Choose the language of these 3 that appeals to you the most, you will not be disappointed. I'm not going to tell you which one to choose, I think you'll be happy with whichever of these 3 languages appeals to you the most.
If you don't mind filling in the occasional gap, and like the bleeding edge of newness, try Rust, or Go. I've done both, they're fun languages with interesting paradigms (built-in lightweight threads vs. memory-safety at all costs FIGHT!).
Getting less attention? According to what? Did you see the the link about dominating science? Attention according to what group of people?
21% of the Internet uses Wordpress, which is built with PHP.
The only concern I have for Python is exactly the temptation to keep adding features and chasing other language's tail lights. I've recently gotten the chance to see a fairly novice programmer dip toes into some Python-based testing code, and it's definitely gotten pretty easy to make awfully magical and complicated Python code after all the decades of accumulated features. They get a very different experience with Python getting the whole thing dumped on them at once than I did riding with the language from roughly 2.0 and watching the features come in one by one.
Python has many advantages over, say, Go right now, but the advantages that Go has over Python, Python is not in a position to reasonably add to itself. Is it "future-proofing" Python, or is it taking something already pretty complicated and crusting on one-too-many layers of "features"?
Exactly, one could use the same criteria of the OP and conclude C is "dying", and how wrong they'd be.
Just because it seems like there isn't new and hot stuff for Python doesn't mean it is actively used and sought after today. Perhaps it's strange because Python always seemed like the hot new scripting language thing until it now where it has become the well known scripting language thing it is today
And you realize it when you explore the QUALITY of python libraries out there. You know what I mean. Quality in Python code sucks.
Python I'd say is in a similar boat. Strong and established with tons of libraries, not popular amongst the kids.
Edit: Apparently my use of "kids" as a sarcastic way of referring to those who won't use "old" languages was missed. :)
Python was doing just fine until Python's little tin god came up with Python 3 and tried to drive a stake through the heart of Python 2. That backfired, badly; six years on, Python 2 still has far more production use than Python 3. (No, it's not about Unicode. Python 2.6 and later do Unicode just fine. I've written sizeable all-Unicode systems in Python 2.6. It's just that in 3.x, it's the default.)
Coming up next, Python 4, with typing syntax that isn't checked. Ugly typing syntax - some in comments, some as annotations. There's an argument for optional type declarations that are checked, but unchecked declarations are trouble waiting to happen.
The PyPy crowd has brought off a miracle - an optimizing compiler for Python that supports almost all the dynamism of CPython. It took a long time, but they did it. CPython should be retired now, or made to conform to PyPy. But no; the little tin god insists that his CPython defines the language. The PyPy developers struggle to keep up.
The language isn't the worst problem. It's the wildly variable quality of the libraries. The great thing about Go is that it has libraries which are used internally by Google, and thus have been executed billions of times. Python's PyPi (formerly Cheese Shop) has no quality control, and many versions of very similar libraries, each with different bugs. There's no convergence.
ISO Standard Pascal is useful mostly as a teaching language. You can't do much real work in it. So Pascal fragmented, badly. There were lots of incompatible variations. In time, Pascal was abandoned.
Sometimes the original language guru has to be pushed aside before they run the language into the ground.
[1] http://www.ryan-williams.net/hacker-news-hiring-trends/2016/...
It's a bit dangerous bias/distortion, you can easily trick yourself into thinking that everyone is running everything with docker, soon everyone will be spinning up clusters with tensor flow to compute on their petabytes of data :) (nothing personal, OP, just something I've noticed lately).
Python is a beautiful language, and what I like to call programming at its purist. It removes the distraction of syntax from the task of problem solving. It's simple enough that a 7 year old can grasp it, and yet powerful enough that Google used it for its TensorFlow's API. Python syntax is so close to pseudocode, that I'll often code a solution in Python, see that it works, and then recode it in Java. It's difficult to describe if you haven't spent 7+ years using Java, but it's way more satisfying debugging Python code than rewriting solutions in Java.
I still use PHP and bash a ton, will use Java in school next semester, used C# during my internship, but Python is among my core tools right now. I notice that library support for Python is so, so much better than for PHP, making my life a lot easier at times.
As for Go, I still intend to look at it, at some point in the future. Basically like I intended to look at Python three or four years ago.
Javascript, yeah for in browsers.
Julia? I heard of it but I still think of the girl first and the language second. Never looked at it and don't see it come by that often. Data science you say? I thought R was hot there, a language I was going to look at somewhere in the next few months (my girlfriend will get it in university, good opportunity for me as well).
Pip is just OK. It feels like it's missing something. Could be a simple lack of experience still. I haven't found anything like Gaurd yet and yet to find a replacement for rack and NPM 's simple package.json. There is setup.py but it feels harder and wrapped in mystery still and doesn't work universally the same for Python 2 and 3 which I have been causing some road blocks and extra cycles being wasted.
Most of all I hate the backward compatibility issues of Python 2 to 3. I rarely have issues running older Ruby or Java code in newer versions of the language. It seems ridiculous that it's been a little over 7 years and people are still fighting with issues between Python 2 and 3 and you still need to pick a version to use. Sure you can code around it, but why the interpreter doesn't handle backward compatibility with deprecation statements is just amazing to me. This isn't a new thing. Languages like Java and Ruby do it as do plenty of others I'm sure if you wanted to make a syntax change you can handle the code in the interpreter and issue warnings to uograde them without breaking all old code bases.
But any ways, I digress, I don't think Python is going anywhere. Too many people and companies use it. It's got a lot of good libraries and and if you just start with Python 3 it's language is just like any other programming language. It's got some things you have to get used to that are unique to it but in the end, you can make it do what you need.
I personally think Ruby allows for nicer looking code and readability, and NodeJS has a far better Eco system. Hell, Languages like Elixir feel like a nice mixture of both with the huge added benefits of being highly parallel at the VM layer.
PyPy seems like a better place to invest resources since the JIT can really speed things up.
That's my 2 cents.
Have you ever actually used Ruby?
Here's what FizzBuzz looks like in Python:
def fizz_buzz(number):
if number%3 == 0:
return "fizz"
if number%5 == 0:
return "buzz"
return str(number)
for num in range(1,101):
print(fizz_buzz(num))
People on HN keep saying Ruby is intuitive and easy to learn -- no it isn't. The Python code by contrast is basically the same as the pseudo code you would write on a napkin in "not-any-particular-language-I-just-want-to-describe-an-algorithm-without-language-specific-issues-to-get-in-my-way".
[1] http://hostiledeveloper.com/2014/04/26/on-why-learning-to-pr...
def fizz_buzz(number)
if number%3 == 0 then
return "fizz"
end
if number%5 == 0 then
return "buzz"
end
return number
end
for num in 1.upto(100) do
puts(fizz_buzz(num))
end
(Also your code is wrong - it never prints "fizzbuzz" which it should for 15, 30, 45, etc.)
I think Python could easily be replaced --- for greenfield projects --- by something better, but there's nothing better right now, and more and more people will keep using Python for that very reason.
`','.join(pieces)` just seems unnecessarily weird, and present simply for OO's sake. Not everything needs to be some object's method.
>>> phrases = [['a', 'b', 'c'], ['d', 'e']]
>>> print(list(map('-'.join, phrases)))
['a-b-c', 'd-e']- Non-performance-critical command line tools for game-data export-pipelines that I previously wrote in C/C++: Python code is usually more compact, and everything I ever needed is in the standard library. If performance is critical I still prefer python to call out to minimal C or C++ tools which do the heavy-lifting.
- Replace native shell-scripts and Windows batch files with portable python scripts that run on Windows, Linux and OSX.
- Stitching together 3D content-creation-tools and command line tools, most DCC tools of have become python-scriptable in recent years.
- Code generation for C/C++ and shader code.
These are all very pragmatic and simple things, I don't care whether my python scripts are 'pythonic' or elegant, and I don't care about the 2 vs 3 debate. Python gets the job done, works everywhere, and I enjoy writing it because of its friendly syntax and powerful standard library.
Python strikes an amazing balance in being a rapid development but also sustainable language, that makes for maximally maintainable code.
While I can't speak for it's growth in data science, it's widely used in systems programming and web development and web services as well.
Go is simply not as agile, it's a lower level systems tool for "tight" low-level code, yes.
Python has never been a front end language. I still think Javascript is a HORRIBLE language, but that's beside the point.
At least from my experience, it's exactly in the perfect sweet spot of language design for being unexciting and getting massive amounts of work done.
A tad bit old, but read this: http://www.curiousefficiency.org/posts/2012/10/pythons-futur...
TL;DR: No.
My take is Python 3 has done more damage to community than we accept to recognise. Python 3 has taken a strong academic approach to make the language better while being valid made it feels like a regression compared to Python 2. The 'print "abc"' not working anymore without brackets is a good example of it.
If the above is true, the Python language has outlasted the Python developers - like C.
Bottom line is that performance does not predict whether a language will die or live. That's not what most people care about.
Actually those 3 things are much simpler in Go.
I've always used Python, but I'm starting to wonder if I didn't back the wrong horse. I've been dabbling with Erlang as my side-language for a years, and Elixir is extremely intriguing to me. I'm considering using Ruby for a new project simply because the syntax is closer to Elixir. A Ruby+Elixir shop makes a ton of sense.
I think the better question would be "is Python losing focus?". The answer to that would be yes. Which includes not only the ~8 year Python3 debacle that's ~10% complete from a usage standpoint, but also the Python3 feature soup. They've just added a 4th string formatting method in Python 3.6.[0] I don't even have words for Python3's feature soup, it's absurd in its own right.
[0]http://learning-python.com/books/python-changes-2014-plus.ht...
My opinion: Python will outlive the three languages you list. But it's dying outside data science, and maybe even there. Optional typing can't compete with modern type inference, and there is too much dynamism in the existing Python ecosystem (even though it's so rarely used - there's not a monkeypatch culture like in Ruby - it's used often enough that you can't just remove it). But not today, probably not in five years either. In fact with the community finally having rallied around 3.x this is probably the best moment in years to leap into Python.
But yeah, all languages are dying, some faster than others. You have to make your own judgements, and learn general skills so that you're not bound to one particular language (unless you're very confident in that one language).
If you want truly survivor languages look at Smalltalk. More than 30 years and still alive. Is not about modern type inference or dynamism... it's always about the people. And people in Python doesn't have that commitment with the technology, they are more like freeloaders.
Machine learning also, at least from my academic view, seems to be dominated by C++/Matlab/Java/Python (and things seem to be moving to Python).
But more broadly, you'll have to learn dozens of languages as a programmer anyways. I wouldn't get too caught up in Python vs. other things.
Look more at what you want to implement, then see if Python makes sense as a language.
Additionally Python should then allow the (explicit) casting of WTF8 datatype to bytes and from bytes to WTF8 datatype (edit: note, I mean invalid data would be read, stored within a WTF8 datatype as such, then converted /back/ to an invalid UTF-8 bytestream identical to the one read in).
The main reason that Python Unicode handling is broken is that it creates problems that aren't necessary to exist or solve. In the real world, you encounter unvalidated data; and many times you don't /care/ if it's valid. It's just some human name for a bytestream. Or some not-quite valid Unicode stored within a file, or maybe something else that you want to handle like a bytestream but pick matching Unicode bits out of.
If you are starting your own company or a side project choose a language that a) best suites your needs and b) you know. Unless your goal is to learn a new language you probably don't want to write your business logic in a completely new language just because it's popular at the moment. And outside of stuff you actually have a say in (i.e. stuff you do for your employer) it doesn't matter what language(s) you know as long as you know something that's applicable.
I learned PHP as my first language (well, I wrote some VB stuff for school before that, but I never wrote it on my spare time), after that I went on to JS just before college and in college I learned C#/Java, but also for my web side projects (which I made some money from) I learned Ruby. Now since graduating I've also dabbled in Python and very lately little in Perl6 (just because the syntax looks so nice), but for my actual job I'm mostly working with Python. It's not my favorite language, but my Ruby and JS (as well as general programming knowledge) carries me through the tasks, it's not like I'm in completely different world where I can't function.
My point is as long as you know how to program the language shouldn't matter, obviously jumping from something like Python to C++ is a bigger change than going from Ruby to Python, but it's not imposible and if your employer really just cares about your languages they are either super specialized and doing some weird shit (which might be your thing and then all you can do is to learn that language) or they really don't know what they want/need.
I'm very excited about Elixir for example. There is a new Elixir blog post/article/github repo posted on HN every day, you would think that Elixir is the new cool thing. Well, not easy to find companies that actually use it.
It's built on technology older than Java. I'm not sure most people need what it offers immediately, but it's certainly a safer bet than most new things. Including CPython3 and Perl6.
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)?
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/
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.
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.
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.
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...
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...
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.
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?
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.
eg: https://msdn.microsoft.com/en-us/library/ms974552.aspx
http://www.icodeguru.com/WebServer/Python-Programming-on-Win...
Apparently Perl tended to work better than Python though due to not being as picky about whitespace in an HTML script element :)
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
If you graph the popularity I would say the derivative gives you newsworthiness (golang, julia) but the integral gives you the popularity.
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).
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.
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 has never been more alive, IMO.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
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.
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.
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 is 5th place after the three C's and one J.
Would be more interesting to know what language he uses when he finishes his Ph.D.
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.
Just because Python doesn't have zealots doesn't men its dying.
https://en.wikipedia.org/wiki/Lindy_effect
Python (and Fortran), having survived this long, seem destined to live a lot longer than the challengers.
Sincerely, Perl Programmers :)
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.
False
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.
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.
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.
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.
"No."
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:
https://en.wikipedia.org/wiki/Measuring_programming_language...
Is python dying?
The data says "Maybe?"