Live data from Hacker News

Python vs. Node vs. PyPy benchmarks

blog.kgriffs.com

31–40 of 57 posts

Re: Python vs. Node vs. PyPy benchmarks

#31
post #17

Earlier quoted context omitted.

If the web development industry moves from PHP to JavaScript as the main backend language... well, from quality perspective nothing will change. IMO.

If one company gave you a PHP job, and another a JS backend job, and that'd be all you got, would you flip a coin to pick one? Or is this a way to say that you feel more satisfied with your work in Python than with your work in node?

This is my way to say several points:

- If the majority of our industry can make the switch to JavaScript, they'll ruin it in terms of average code quality.

- Even good, idiomatic JavaScript code sucks for reasons inherent in the language.

- I wish people wrote just good enough Python or Erlang or Haskell or whatever code instead of excellent PHP/JavaScript.

So yes, I treat PHP and JavaScript backend jobs equally.

[Edit: grammar.]

Re: Python vs. Node vs. PyPy benchmarks

#32
post #15

I'm actually quite perplexed as to why the blog author chose to use the WSGIRef which is known to be one of the slowest of the bunch according to this much more thorough benchmark: http://nichol.as/benchmark-of-python-web-servers Even more perplexed, why wasn't the payload and the WSGI apps sources published?

Your observation is good. Author should clarify this. But in his next articles he shows benchmark against other web frameworks, which shows more justified results

That doesn't really answer why use the slowest one with PyPy (and no, uWSGI does not work for PyPy, but a lot of stuff does)

Re: Python vs. Node vs. PyPy benchmarks

#33
post #31

Earlier quoted context omitted.

If one company gave you a PHP job, and another a JS backend job, and that'd be all you got, would you flip a coin to pick one? Or is this a way to say that you feel more satisfied with your work in Python than with your work in node?

This is my way to say several points: - If the majority of our industry can make the switch to JavaScript, they'll ruin it in terms of average code quality. - Even good, idiomatic JavaScript code sucks for reasons inherent in the language. - I wish people wrote just good enough Python or Erlang or Haskell or whatever code instead of excellent PHP/JavaScript. So yes, I treat PHP and JavaScript backend jobs equally. [E…

>> Even good, idiomatic JavaScript code sucks for reasons inherent in the language.

Care to elaborate?

Re: Python vs. Node vs. PyPy benchmarks

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

Re: Python vs. Node vs. PyPy benchmarks

#35
post #31

Earlier quoted context omitted.

If one company gave you a PHP job, and another a JS backend job, and that'd be all you got, would you flip a coin to pick one? Or is this a way to say that you feel more satisfied with your work in Python than with your work in node?

This is my way to say several points: - If the majority of our industry can make the switch to JavaScript, they'll ruin it in terms of average code quality. - Even good, idiomatic JavaScript code sucks for reasons inherent in the language. - I wish people wrote just good enough Python or Erlang or Haskell or whatever code instead of excellent PHP/JavaScript. So yes, I treat PHP and JavaScript backend jobs equally. [E…

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

Re: Python vs. Node vs. PyPy benchmarks

#36
post #27
post #26

Earlier quoted context omitted.

It's either fixed or there's a problem on your end.

Nope, I don't get any numbers/labels either. Seems like the website is incompatible with a bunch of browsers.

He's just using Flot, which a lot of us use for canvas-based charts. Do they work for you at all?

http://www.flotcharts.org/

If not, what browser are you using? It would be nice to know if Flot is not compatible with something.

Re: Python vs. Node vs. PyPy benchmarks

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

Re: Python vs. Node vs. PyPy benchmarks

#38
post #3

Node/V8 is a beast and will dominate web development in few years. EDIT: Downvote me, I don't care.

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…

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.

Re: Python vs. Node vs. PyPy benchmarks

#39
post #33
post #31

Earlier quoted context omitted.

This is my way to say several points: - If the majority of our industry can make the switch to JavaScript, they'll ruin it in terms of average code quality. - Even good, idiomatic JavaScript code sucks for reasons inherent in the language. - I wish people wrote just good enough Python or Erlang or Haskell or whatever code instead of excellent PHP/JavaScript. So yes, I treat PHP and JavaScript backend jobs equally. [E…

>> Even good, idiomatic JavaScript code sucks for reasons inherent in the language. Care to elaborate?

I'll just throw a couple pet-peeves of mine in here:

- No proper packaging/namespacing

- Completely idiosyncratic results when operating with mixed data types (10 + 'p' = '10p', 7/0 = 'infinity' and all that)

- Variables default to a pseudo-global scope

- Prototype based 'inheritance', while cool, is just cumbersome and inelegant compared to languages that have proper object oriented language constructs

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

Re: Python vs. Node vs. PyPy benchmarks

#40
post #15

I'm actually quite perplexed as to why the blog author chose to use the WSGIRef which is known to be one of the slowest of the bunch according to this much more thorough benchmark: http://nichol.as/benchmark-of-python-web-servers Even more perplexed, why wasn't the payload and the WSGI apps sources published?

Your observation is good. Author should clarify this. But in his next articles he shows benchmark against other web frameworks, which shows more justified results

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.
Post reply on HN