Predicting what will be the next language of the decade is more interesting. My bet is on Javascript for now.
Predicting what will be the next language of the decade is more interesting. My bet is on Javascript for now.
No big deal to be ~50 times slower than native code in a single-thread, single-processor use case, but for a well-parallelizable problem on a multicore machine you end up being several multiples of ~50 times slower.
Google just gave up on trying to optimize Python (see Unladen Swallow project) and told the engineers to move on to something useful. I am not sure if the interanls are just to messed up too make it work or if resistance and denial on the part of "B"DFLs and the community is too strong.
But when javascript - JAVASCRIPT! - has a better server-side concurrecy pitch than your language, it is in big trouble
"Well, simple common sense is going to limit Python's applicability when operating at Google's scale: it's not as fast as Java or C++, threading sucks, memory usage is higher, etc. One of the design constraints we face when designing any new system is, "what happens when the load goes up by 10x or 100x? What happens if the whole planet thinks your new service is awesome?" Any technology that makes satisfying that constraint harder -- and I think Python falls into this category -- should be discouraged if it doesn't have a very strong case made in its favor on other merits."
And note this was before the failure of Unladen Swallow, before van Rossum's departure.
But my point is about the client side. We don't have much of a choice between client side languages, but we do have a choice about how much we do on the client in the first place. That equation has changed quite dramatically over the past decade thanks to new JavaScript runtimes.
Most people using node just use a PAAS too.
[Edit] Or did you mean to say that most people use node on a PAAS? In that case it's not a tautology, but I don't think that most people do, and I didn't say node was easy to set up.