"Write in Python/Ruby/whatever and optimize the slow parts in C" echoes around the programming community endlessly, but I wonder how many people have actually done it. It's kind of hard.

- Automated tools like SWIG have weird limitations and are complex.

- Binding to a C library manually means you have to wrangle the data from a heapy, pointery dynamic language world into whatever format the C libary wants.

- Writing the C code to operate on the dynamic language's objects directly means you have to learn how the language works under the hood, and your C code will never be useful in any other language.

- Python and Ruby both have a GIL that prevents you from using multithreading to its full potential.

- The way dynamic languages lay out objects in memory causes an inherent slowness everywhere. Your app's slowness may well be a death of a thousand cuts, with no easily optimized hot spot.

I think anyone who has actually worked on a project built this way will appreciate the idea of a compiled language that is closer to the expressiveness of Python.

This isn't an assertion, just a question: isn't that exactly the reason why Cython exists, both to more easily facilitate the connection between Python and C, and to create essentially "a compiled language that is closer to the expressiveness of Python"?

Yes.

I have done it a lot. However, I optimized the slow parts in C++ with Boost Python, not C. It is not hard and it works great and is well documented.

Writing your application in Python/Ruby/Whatever and optimize the slow parts in C sounds like a good way to have the worst of both worlds: the lack of efficiency of the interpreted language combined with long development time, difficulty porting, buffer overruns and segfaults of C programming.

V8 + C++ has served me pretty well; C and Lua likewise.

Lua bindings are so wonderfully straightforward. A happy consequence of the design goals.

So you're arguing that it's "hype" because while it's all true, it doesn't matter if something is I/O-bound. Even if you're right, a server farm that uses 5x fewer CPU cycles is saving a lot of electrical power. 5x is of course a very conservative estimate.

I remember this argument being made in favor of Java (over native compiled code) and there it at least had some credibility. Python and Ruby are far, far slower.

Certainly, the only credible/really important argument in favor of Python (or whatever alternative language you want to suggest) is programmer productivity. Get the feature out the door, and then when it's making money figure out how to optimize it. If I were going to pick on anything in the article, it's the long line of "}"s in the HTML generation example. One of the best arguments in favor of Python's indentation I've ever seen.

All this theoretical bottleneck debate, but it really boils down to this:

If you're writing frequently-run code in Python/Ruby/JS, or any such highly-dynamic-at-runtime language, then chances are very good that your CPU, memory access, CPU cache, etc are going to be part of your bottleneck.

Write in something that doesn't effectively turn an i7 into a Pentium 4 (and be sure to use efficient memory management techniques), and your chances of main bottlenecks being IO-only are much better.

The belief that IO is the only bottleneck is a self-defeating prophecy. It leads to code and techniques that cause CPU to become a bottleneck once again. Don't forget Wirth's Law.

Alright, some basics: having data "on disk/network/whatever IO" does not mean that you application will be bound by I/O.

If you care for your application performance you will quickly learn how to cache data (and that means figuring out algorithmic space and execution complexity). You will then, quickly care about how well your chosen programming language, libs and OS deal with memory allocations, instruction parallelization, on-die cache optimization, and so on.

And finally after all that, you will still care about I/O so you will figure out how to optmize your I/O access to benefit from hardware assumptions of a particular set of storage/network devices

Then you will look back at your solution and realize that your "use its wrappings in your scripting language of choice" is nothing more than a wrapper around another language. And then you will be wondering if it was worth starting with a different tool.

would you write Bitcoin in python?

People endlessly parroting the "IO bound" line never post numbers. As far as I've seen it's just not true. Things like web apps are routinely bottle-necked by execution speed, not disk or network.

Well, my experience is that web apps are most often bottlenecked by the database speed, because almost any other problem can be solved with money (and not even much of it).

I've seen databases bottleneck on lots of different resources, even some virtual ones (unexpected serializing). But I'm very suspicious of people claiming that one must write webapps in low level languages "because speed". (And yes, I know there exist problems out there where this is true, the same way that there exist people out there that've won the lottery.)

It depends on the web app. My experience is that being bottlenecked on the database, while natural, is so crippling to scaling that extensive caching is used to prevent the majority of requests from touching the database.