It absolutely is as bad as 'KirinDave says it is, although the article does a bad job of showing it. Node shines at IO-bound applications, sure, but let's say you want to do one big computation on 16 cores all at once.
With Node, you'd have to serialize data and pass it between child processes. And that really, really sucks. Haskell's parallelization story extends way past the "embarrassingly parallel" request handling.
Finally, if you're looking to do something truly and extremely CPU-bound, I'd tell you to write it in a C derivative and bind it to Node or Haskell, regardless of what your favorite language is. Optimize for speed in some places, and programmer happiness in others. A one-size-fits-all approach isn't usually appropriate.
Thats parallelism, and node is as bad as it gets, yes. However, it pretty good at streaming all the necessary data to another service that will do the number crunching, as well as getting the results out to the client (with light transformation if necessary)
Comments
It absolutely is as bad as 'KirinDave says it is, although the article does a bad job of showing it. Node shines at IO-bound applications, sure, but let's say you want to do one big computation on 16 cores all at once.
With Node, you'd have to serialize data and pass it between child processes. And that really, really sucks. Haskell's parallelization story extends way past the "embarrassingly parallel" request handling.
A good data point based on a less contrived example is how handily Haskell web frameworks demolish Node.js at JSON serialization... and not much else (https://www.techempower.com/benchmarks/#section=data-r13&hw=...).
Finally, if you're looking to do something truly and extremely CPU-bound, I'd tell you to write it in a C derivative and bind it to Node or Haskell, regardless of what your favorite language is. Optimize for speed in some places, and programmer happiness in others. A one-size-fits-all approach isn't usually appropriate.
I just spawned a least-latency load balancer in front of a cluster of N processes (one per core) for the benchmark.
https://github.com/spion/fpco-article-examples
Now it gives the same results as the Haskell solution. (Which only means this concrete benchmark doesn't reflect real world performance)
Thats parallelism, and node is as bad as it gets, yes. However, it pretty good at streaming all the necessary data to another service that will do the number crunching, as well as getting the results out to the client (with light transformation if necessary)