HN runs on a single core. Arc is implemented in Racket, which has green threads, so requests don't block on I/O. Whether that counts as concurrent is sort of definitional, but the CPU isn't processing two requests at once.

Interesting to keep in mind whenever a link that makes front page of HN drives 20-30k clicks to some "scalable" web app spread across a couple racks of machines which is then annihilated under the "load".

Actually, it shows you how incredibly inefficient most other ways of building a web application are. The amount of overhead is stupendous.

There are different kinds of overhead, different kinds of inefficiency.

The HN codebase doesn't have the overhead of parsing hidden POST fields (for example), but it does incur a massive RAM overhead to store all that information as closures.

A run-of-the-mill web app, on the other hand, would incur the overhead of passing state back and forth, and perhaps even store sessions on disk. But it might consume less RAM.

What matters is what kind of inefficiency you're willing to tolerate in exchange for what kind of benefits. RAM overhead is a smart choice if you want your app to be very fast and you can afford to use a lot of RAM. A different organization, however, might choose to incur a bit more code-complexity and slower execution in exchange for other benefits. It all depends on what your priorities are.

Yes there are tradeoffs, but I'm not sure this is all that great of an example: a slower application and harder to maintain code are simply not worth it. Computers are cheap - devs and customers are expensive.

That is pretty amazing that it keeps up with the traffic.

As far as I can tell, it was always the case, yes.