PyPy is a project to bring some optimization to Python. Basically make Python run faster. It is also effectively another implementation of Python. CPython is the default one (the one you download at python.org). There is also Jython (running Python on the JVM), and PyPy, and a few others.
NodeJS is the marriage of the V8 Javascript interpreter and JIT with an asynchronous IO library (libuv) + a large ecosystem of modules.
You might want to compare nodejs with PyPY+Tornado or with PyPy+eventlet. Read about STM and the idea behind it. STM lets you take advantage of multiple cores. nodejs is single threaded. In practice nodejs might be faster currently just because V8 is very good and depending on workload if most of the stuff it does is just proxying data from one stream to another, it might do pretty well. But if you start doing a large number of concurrent requests where each request has do to some logic, PyPy might come out on top.
In general anywhere with complicated business logic or a large number of steps needed in the backend to handle requests, I wouldn't use nodejs. I never liked the callback/errback paradigm for large concurrent applications. That works for demos and short web tutorials, in practice, I don't like how it looks. I like green threads, lightweight processes better.
"In practice nodejs might be faster currently just because V8 is very good" and I presume you claim PyPy is not so good? Well if so, I would really like to say [citation needed], especially for workloads and not say computer language shootout, which has little to do with performance of doing any actual workload.
Of course not, Maciej ;-) PyPy is awesome and thank you and the whole team you have been doing a great job so far. Just looking at performance graphs and speedups gained over the years. It looks very impressive.
Yeah I don't have a citation but from experience, I have noticed where there are a few steps in each request processing (think proxies) solutions based event loops (epoll, kqueue and friends) can outperform those that spawn a thread/process/context. For example haproxy is certainly a very well done fast proxy, it is single threaded and it seems to work for it.
Again sorry for misunderstanding, I was just speculating without any benchmarks or even particular applications in mind.
Cheeky comment aside, PyPy is an alternative interpreter for Python and, more broadly, a meta-frame work to make writing tracing JIT for the language of your choice easy.
It's much faster than regular Python. The only downside (which, admittedly, is very, very big) is that the PyPy developers released their own FFI library for interfacing with C-code (which works brilliantly), but using c-types and the c-python c-api is very kludgy. This means that a lot of very important python libraries which are basically thin wrappers around c/fortran code (SciPy, NumPy, etc) are not really working.
There is some effort around reimplementing NumPy in PyPy, but it's going very slowly.
Edit:
PyPy is also a heroic effort by a small team of developers who receive some donations. JS is probably the language that received the most amount of money and attention into making it run fast from Google/Mozilla, etc - in terms of results/money, PyPy is incredible.
To be a bit more specific, pypy can be much faster, for certain usecases. For others it may not be, or it may be even significanlty slower - writing JIT for python is not an easy task.
Sigh, I'll give you the only honest answer it seems you will get here. Node.js runs JavaScript faster than anything runs Python, PyPy included. If you want speed and you like JavaScript just as much as Python, then use Node.js. When I say "faster" I mean you will use less servers/cores for your application with Node.js than you will with CPython or PyPy. V8 is just a better and faster VM for its target language.
"Node.js runs JavaScript faster than anything runs Python, PyPy included" that's a [citation needed] right here. Do you have some facts that I don't happen to have? Please share. That said, I don't care about a recursive fibonacci or computer language shootout problems.
Benchmarks are all you need to know unless a language runtime has IO problems. Fewer instructions and less memory mean fewer servers. Benchmarks are really good at predicting general performance. Languages with slow benchmarks need more servers to run your app. Languages with fast benchmarks need far fewer servers to run your app. This fact is so obvious and testable that I don't know why slow-language people bother throwing up the argument that benchmarks aren't everything.
Repeat after me: languages don't have speed.
Maybe to someone who is just now getting into the industry, but it wasn't long ago JS had no speed.
Python also varies in speed over time and implementation. Implementations have speed. There are reasons that people use "slow languages". It's not just developer happiness. You really do have to look at performance holistically.
If you want to speak to microbenchmarks, I can. For example, CPython's std lib JSON processing is done in C. It's very fast. As of Go 1.2, PyPy blew the doors off Go in my tests processing 10,000 JSON records. CPython 2 & 3 also beat Go in my tests as well. What's this mean? Does it mean Go is a slow language? Well, it's one microbenchmark vs another. It really doesn't mean much to your application.
"I don't know why slow-language people bother throwing up the argument that benchmarks aren't everything."
I'd go even further than 'aren't everything'. Benchmarks that aren't your application do not mean anything.
Many are ignorant of how CPython is even built and are shocked when I show them how fast many standard library modules are. It's just not so simple. Don't believe the hype.
What benchmarks? Benchmarks are specific to the application area. Computing n-body simulations are not good benchmarks for a concurrent application that servers web requests, connects to databases, and processes credit card data.
But that wouldn't be a true statement. Google's engineers didn't laugh at Node.js for using V8 due to arrogance. V8 is limited to a single CPU thread per instance. It's great for I/O and a typical webpage, but a CPU task stops everything. PyPy with STM does not have this limitation. Once this project is out of beta, V8 wouldn't compare to PyPy/STM. A better comparison would be the JVM or CLR.
