His articles don't justify anything. I don't know what his payloads are or how he produced them in the apps. For all I know these 2 "benchmarks" are unreproducible. The author said he wanted to try science, there's nothing scientific about these 2 articles at all.
uWSGI works with PyPY (Obviously with lot of limitations on the features). http://projects.unbit.it/uwsgi/wiki/PyPy
The problem is that for the vast majority of the webapps there is (still) no advantage. I only wanted to focus on that as i have invested days on (really complex for me) pypy sources, and i do not want people to ignore it ;)
This whole test says more to me about the performance of non-blocking MongoDB drivers than it says about the underlying performance of the frameworks/languages. The python tests lacked a non-blocking driver. Why not use the PostGRES drivers ? That would give a much more accurate and fair treatment.
And for the record, I don't care one way or the other which is "faster," just make a damned test where one isn't given such a clear leg up.
I am not sure it will always under-perform with one CPU. It depends if async threads are used and if kernel poll is enabled. Erlang is designed for better low latency response at the expense of _some_ sequential slow down. I wonder if Erlang would scale slower but it will throw less errors as number of requests increases.
Also it would seem benchmarking Erlang and forcing it to run on a single core just like node.js is deliberately handicapping it. One of the strengths of Erlang is exactly the ability to take advantage of multiple cores.
Facebook was built on PHP and MySQL, both of which are awful pieces of crap.
Twitter went down like every week for a year. It was written on RoR by people who didn't really know RoR.
Meanwhile, a bunch of better engineers using better technology got their clocks cleaned while the winners eventually had so much money they could afford to hire an army of engineers to rewrite everything.
You know the graph I would like to see? A scatterplot of how good various startup founders and early team were on engineering vs finding a market fit, with the dots labeled with how rich they are now.
Just FYI, in my own tests I've found Node.js performing about 50% better (req/s) than Tornado/C-python, while Tornado/pypy comes very close to Node.js' performance. Tornado is one of the fastest Python web frameworks and does not use WSGI (by default).
The point is that pypy can crunch almost as fast as Node.js, so while Node.js may set the standard, Python is not bad choice either from performance perspective.
He carefully chose to use a really bad combination for pypy (or uncarefully, always assume stupidity over malice). Fast options for PyPy are cyclone.io or tornado (or eventlet or gevent on a branch I'm working on, although it's not done).
Red & green is the stereotypical colorblind test, that's a pretty obvious combination to avoid. It's easy to choose colors that are at right angles in the color wheel, and that's not how accessibility works - you can't require every paraplegic to have a special wheelchair that can climb stairs, despite it existing...
JS is a modern and beautiful language, comparing it with PHP is bold. People fighting Node are just afraid to change and to start from zero again, they fear the truth.
No other language offers C-class speed, that rich ecosystem (which is fully async) paired with such an easy approachability plus the best and most modern package manager around. Speed is not everything but users won't tolerate unresponsive web services based on sluggish language implementations and cumbersome frameworks anymore, it's not 2005.
Why do you think did Airbnb, LinkedIn and many more choose Node in production for high traffic apps?
Don't get me wrong, Python, Erlang, Haskell are great languages, I love them all but since V8/CrankshaftJIT/Node, JS is playing in a different league with an amazing cost-benefit ratio and I am confused by people ignoring this (however, I see rather Go and Clojure as real contenders to JS since they offer modern language concepts too paired with speed and real concurrency but they are again compiled and deploying JVM based stuff (Clojure) is no fun at all).
- Completely idiosyncratic results when operating with mixed data types (10 + 'p' = '10p', 7/0 = 'infinity' and all that)
I wouldn't call it idiosyncratic but just use Underscore and you are fine.
- Variables default to a pseudo-global scope
just use 'var' when declaring them
- Prototype based 'inheritance', while cool, is just cumbersome and inelegant compared to languages that have proper object oriented language constructs
Any OO is cumbersome and should be used only when it makes sense. If you don't like prototype based inheritance you can still use traditional OO with extra libs.
- Take all those and a syntax that was partially taken from Java, and you end up with verbose code jumble that is way more difficult to read than equivalent Python/Ruby (even C#)
Sorry to disagree again but there are many people preferring bracket based languages over those omitting them. You can quickly identify blocks and navigate through the source. And JS isn't verbose like Java.
JS has its quirks like any other languages but these are just very few and you get tons of amenities in return.
I actually don't think so, not that I have downvoted you.
V8 was such a breakthrough at the time, it blew off the competition. Since then, many competitors have picked up the tricks and as shown in the bennchmark, uWSGI holds its own against Node/V8. As a result, the Node/V8 combination is not going to be so dominant in a few years in terms of performance. Another factors will come into play such as the language and the libraries available (the ecosystem). I would find it much harder to predict the dominance of the Noode/V8 ecosystem compared to that of Python or Java in a few years' time.
I think this is it exactly. The pace at which infrastructure, support and tools in "competing" ecosystems can be improved will outpace the rate at which people's miss can be changed about JS. There are 10-15 years of the language's, most of which were a Very Bad time for it's reputation, and only recently has the community of developers begun to land on solid development principles -- and you can hardly call those universal. I think most people fear callback spaghetti when they think of diving into someone else's JS code.
A quick google  results in this article. Look for JS:V8 - Node runs off of that. Most of the graphs I glanced at show it's very close to C. I glance because I've properly checked out other benchmarks which confirm this.