> Well the other option for computationally expensive code is to use some sort of worker that runs a sufficiently fast language.
Which only helps if you know your code is going to be slow. If you somehow implemented an algorithm with a quadratic complexity and did not test for sufficiently large input, you might not realize what's going to happen before it hits production.
> JavaScript on v8 is actually one of the fastest interpreted languages available
1. Nobody is denying that.
2. The issue is with the behavior of evented systems in general and node in particular in case of in-request CPU-bound code paths, namely that the whole server blocks killing concurrency and basically DOSing the instance.
Which only helps if you know your code is going to be slow. If you somehow implemented an algorithm with a quadratic complexity and did not test for sufficiently large input, you might not realize what's going to happen before it hits production.
> JavaScript on v8 is actually one of the fastest interpreted languages available
1. Nobody is denying that.
2. The issue is with the behavior of evented systems in general and node in particular in case of in-request CPU-bound code paths, namely that the whole server blocks killing concurrency and basically DOSing the instance.