MagicStack, the company behind uvloop and asyncpg, writes benchmark-driven posts on fast Python networking and Postgres access.
HN commenters cite it as evidence that uvloop and asyncpg make Python asyncio fast, and note aiohttp's HTTP parser is slow by comparison.
When people say cpython is slow they are generally pointing to two things
1) The interpreter is _slow_
2) You can't achieve real thread based parallelism
I think in general people have a high level concept of (1) as static vs. dynamic and interpreted vs compiled is an understandable trade off. CPython as an implementation generally gets type casted as slow for its default dynamism which have understandable negative performance implications[1]. However CPython also gives you lots of ergonomic ways to push your program towards the static/compiled end of the spectrum with things like pandas/numpy/numba/extensions. In general using these correctly put you within the ballpark of _faster_ languages, could you write faster assembly by hand? Sure! Is optimizing in another language worth your time? I don't know.
I've never really understood (2) the lack of threading as a problem, multi process parallelism can be accomplished fairly easily if you are CPU bound or projects like uvloop[2] make async tasks fast enough to compete with any web framework out there. Furthermore even though your cpu cycle cost may be levered to a considerable point while operating over hundreds/thousands of servers doing distributed computing right is still hard and developing something like celery/airflow/luigi/dask from scratch is not cheap either. Leaning on CPython's massive ecosystem can massively lower the barrier to entry in a lot of big problems.
I think there are plenty of examples of re-writes…
Let me point out two alternatives:
Cython which is very Pythonic looking, and compiles to C and produces amazing projects including UVLoop which is a drop-in module for asyncio for Python 3 that will speed up asyncio:
https://magic.io/blog/uvloop-blazing-fast-python-networking/
https://github.com/MagicStack/uvloop
Note how GitHub claims it's all mostly Python code ;) That's because Cython like I said looks Pythonic.
There's other examples, but I think this is one of the one's that come to mind the most to me.
There's also D which is called Native Python by some (unlike projects like Go and Rust, you can have your Object Oriented Programming (optional like in C++), and concurrency / parallelism too and other goodies like built-in unit testing, when you compile your code your unit tests are ran but not included in the final binary):
http://bitbashing.io/2015/01/26/d-is-like-native-python.html
https://blog.experimentalworks.net/2015/01/the-d-language-a-sweet-spot-between-python-and-c/
If it's been more than a few years since you've evaluated D you might want to check it out again, it may be worth your time. D is a language I knew about for years, and recently is where I've come to appreciate it for it's many features.
D has things like array slicing, [OPTIONAL] Garbage Collection, an amazing Web Framework called Vibe.d with it's own template engine called Diet-:
http://vibed.org/
https://vibed.org/blog/posts/introducing-diet-ng
Things I like is Vibe.d is not just a…
> It's objectively not perfect, but then most languages have problems.
Let me be clear here: JS is not really any better or any worse than any other interpreted languages. Yeah, I can name a few language-level problems (whoever decided that Promises should silently eat exceptions was wrong), but the big problems are not unique. Things like awful numeric performance (I've done crypto in JS), horrible multithreading support (Python and Ruby have GILs so it's roughly the same thing), etc etc.
The difference is that JS/web programmers seem to be the only ones saying that things written in their language and platform of choice (JS/HTML/CSS webapps, inside or outside of Electron) are the future everybody wants. Like the ego-stroking whenever somebody posts a new Node or Electron tool that had no reason to be written in JS except that the developer just didn't want to use another language isn't weird. Like 123mb for a terminal emulator isn't ridiculous.
Javascript brings nothing to the table except that it's the only language you can use for web programming. Nothing.
The execution model is awful as well, since apparently in order to get any sort of decent performance in a webapp these days you need to maintain a shadow copy of the DOM just so you can hack around the browser's layout engine.
> JavaScript has some of the most advanced features of languages available today, including lambdas, closures, and asynchronous coding patterns that make it faster at dealing with IO than…
You can write a fast server in Python 3 that can benchmark well against Node [0].
The author tried to sell us on the idea that Python is slow because Django is slow and you shouldn't use Ruby because Rails is slow. You should just use Node because its fast.
Well I don't know about you but I've seen slow Node applications too.
It all comes down to data. If you really want to maintain your performance goals you have to include them in your design. You have to design for your data. Show me your data and I can write the program. Design it well and you can scale up when the time comes with minimal effort.
Besides there are other factors to consider such as familiarity with the tools, correctness of the implementation, etc. Javascript is great and all but it is incredibly easy to make errors that will go unnoticed until it hits production. The law of large numbers won't protect you if you're used to the blanket of obscurity. And so I find you need many more layers of tooling and choose your subset of the language carefully to maximize its use... something that you don't have to do as much with OCaml or Haskell for instance.
Hence, "just use Node because its fast," is misguided at best. (And I'm not even a Node hater.. I maintain a number of Node applications presently).
[0] http://magic.io/blog/uvloop-blazing-fast-python-networking/
I'm getting confused. Are you trying to do parallel compute or parallel networking?
If parallel networking, the benchmarks I've seen set Python asynchronous IO at about the same speed as Golang. The folks at Magicstack reported that Python's bottleneck was parsing HTTP (https://magic.io/blog/uvloop-blazing-fast-python-networking/). Note their uvloop benchmark was about as fast or faster than the equivalent Golang code.
If parallel compute, then multiprocessing is the way to go and Python's futures module ain't clumsy. It's just ``pool.submit(func)`` or ``pool.map(func, sequence)``. If you're asking for parallel compute via multithreading, you're going against the wisdom of shared-nothing architecture. Besides, pretty soon you'll want to go distributed and won't be able to use threads anyway.
In contrast to your experience, I find Python makes it easy to write efficient code. Getting rid of the irrelevant details lets me focus on clear and efficient algorithms. When I need heavy compute, I sprinkle in a little NumPy or Numba. My bottleneck is (de)serialization, but Dask using Apache Arrow should solve that problem.
> Python I/O also releases the GIL (and has for decades).
I didn't know this; thanks! I'm not familiar with Python internals at all (in fact, I had to look up what GIL was when I read the article). Seems strange, then, that the author would imply a contrast between Python and node.js (which I'm now realizing was your point to begin with). Thanks for being patient with me :).
> And FWIW, libuv is also available in Python.
> https://magic.io/blog/uvloop-blazing-fast-python-networking/ claims significantly faster than nodejs.
Yep! There are bindings for quite a few languages now. The only reasons why I conflate libuv with node.js are because libuv was developed specifically for node (as a cross-platform libev implementation) and because libuv comes with node by default.