> Also, most other web stacks will discourage you from running a 30s fib on a thread processing web requests. This isn't specific to node.
Difference being, with other stacks a request running for 30s will have little impact on the rest of the machine. With node, the whole server gets stuck, not just that precise request and the machine resources necessary to perform the computation (or whatever).
The fib example is extreme, but it's rooted into a real issue of cooperative multitasking: code does not always behave correctly and is not always perfect. You might have used a quadratic algorithm and it ran in 10ms on 10 items or so, but in production it happens a user is getting it to run on a hundred or a thousand items, and now other users are severely affected, in that their requests are completely frozen while the computation is going on. There are hundreds of other possibilities, small inefficiencies, shortcuts, plain bugs, etc... which are basically going to break your node application.
Even if you're not "crazy enough" to do what's prescribed, every user routed to the locked node instance will still be locked. You're just reducing the surface area of the freeze.
Difference being, with other stacks a request running for 30s will have little impact on the rest of the machine. With node, the whole server gets stuck, not just that precise request and the machine resources necessary to perform the computation (or whatever).
The fib example is extreme, but it's rooted into a real issue of cooperative multitasking: code does not always behave correctly and is not always perfect. You might have used a quadratic algorithm and it ran in 10ms on 10 items or so, but in production it happens a user is getting it to run on a hundred or a thousand items, and now other users are severely affected, in that their requests are completely frozen while the computation is going on. There are hundreds of other possibilities, small inefficiencies, shortcuts, plain bugs, etc... which are basically going to break your node application.