12 ms·

Comparing Haskell and Node concurrency performance

129 points by ky3 10y ago

igl 10y ago
Comparing apples to oranges
- lgas 10y ago
  How so?
  - edem 10y ago
    Node has no built-in concurrency just callbacks. The whole point is nonblocking io in node not multithreading.
    - Athas 10y ago
      Concurrency using event loops is still concurrency. Older cooperative concurrent systems used to work that way.
    - tracker1 10y ago
      Node does use threads for async io, it's just abstracted away from the main loop. The bigger issue, is the cpu bound code is a bad use case for Node, and it's known to be. There are options to run this type of code out of the main process though. You can scale node, via the same techniques you use to scale anything across servers, you just do it sooner with node in order to better utilize a larger server, or use multiple servers sooner. Node is great for just about any io bound workflow.
- igl 10y ago
  Downvoted ofc. To be more elaborate: Node never claimed to do multithreading or being good at parallel processing. The shocking discovery of this article is: 1) The Author knows little about JS. 2) Picking on a scripting language which has 2 weeks + 2 years of development vs a 25 year old monster that is the playground of the brightest minds in CS, is easy. Unfortunately the article did also not go into details of how the event loop works or shows how you can break out of the single thread with the tools that ARE available to you. I guess the idea was to write a hype article for Haskell. Here are some more ideas for the author: Comparing Haskell and C++ type systems. Comparing Haskell and Clojure functional purity and lazy evaluation. Comparing Haskell and Java deterministic parallelism.
aconz2 10y ago
The first part about comparing the callbacks in Javascript vs do notation in Haskell is super misleading. The do notation desguars to code that looks essentially identical to the Javascript version. Sugar is not a negligible consideration in system choice, but that kinda thing just bugs me.
- hood_syntax 10y ago
  That's a very fair point. I actually think in small doses the desugared Haskell looks better, but it gets ugly really quickly.
- gkya 10y ago
  Except its not really misleading. The code when you return later you can glance and read is better than that which looks like a landscape rotated counterclockwise.
- efnx 10y ago
  It desugars that way beacause of the nested structure of monadic sequencing, not because of threads or IO. We can distill the real argument down to "JavaScript must use nested callbacks for async. Haskell doesn't."
KirinDave 10y ago
On one thread, I am defending FP from critics who are unaware from the state of the art. EDIT: Just to make it clear early on, I agree with the article's conclusion that Nodejs is not as good at compute heavy workloads as Haskell. I simply object to any use of "the nested callback problem" as valid in 2016. It's an issue exclusively for legacy code and developers who take pride in writing outdated code. It seems only fair, then that I also should defend Javascript from people obviously unaware of the state of the art in pseudo-imperative programming. And by state of the art, I mean "has been around in some languages for 3+ years." The example: request('http://example.com/random-number', function(error, response1, body) { request('http://example.com/random-number', function(error, response2, body) { request('http://example.com/random-number', function(error, response3, body) { ... }); }); }); But modern Javascript (before you start, yes, it runs on every browser with preprocessing, which is normal for this ecosystem) would make it look more like this: // rp is a request promise, multiple options for creating them async function make3StaticRequests() { try { var res1 = await rp('http://example.com/random-number') var res2 = await rp('http://example.com/random-number') var res3 = await rp('http://example.com/random-number') // ... } catch(error) { // ... } } // And of course the promise library allows for many things // you'd like with applicative functors, like binding groups // of operations together and evaluating them all. function randomNumberPromise() { rp('http://example.com/random-number') } async function make3StaticRequests() { var [res1, res2, res3] = Promise.all([randomNumberPromise(), randomNumberPromise(), randomNumberPromise()]) // ... } I don't really understand why people feel comfortable writing up comparison articles without doing sufficient research into what they're comparing things to. That said, the articles point about large compute workloads starving other operations is very much true and a good example of what the weakness of V8 as a server-side programming environment brings.
- spion 10y ago
  For starvation there is also clustering, which can shift the load towards worker processes that aren't busy with cpu-intensive tasks, as well as simple modules such as `https://www.npmjs.com/package/process-pool` https://www.npmjs.com/package/process-pool` which can be used to offload (known) expensive tasks. While Haskell is truly better at concurrency (no need to serialise when passing messages, green threads yield not only at IO but also at memory allocations), that part of the comparison isn't very good. Spawning a cluster of NUMCORES threads using the built in cluster module would be an improvement.
ninjakeyboard 10y ago
Node has concurrency? :P
- leshow 10y ago
  i think you are confusing concurrency with parallelism.
- tracker1 10y ago
  Node uses a thread pool for async i/o flows, it's just this is abstracted away from you in terms of the main event loop. It's really an elegant model, and makes node a great fit for a LOT of use cases. Using the most broadly used dynamic language on the planet probably doesn't hurt as well.
reqres 10y ago
> Which leads to the 'callback hell' that we all know and hate. Part of the bill-of-goods we accept when using Node is that in exchange better time and space characteristics, we lose the thread as an abstraction. Perhaps my head has been stuck in javascript/node land for too long but I think accusations about javascript producing callback hell now seem a bit disingenuous even for relative novices to the language. It's 2016 and there are many well documented and widely adopted solutions arising from external libraries and developments in ECMAScript. Thanks to transpilers like Babel/Typescript we can even shoehorn these new ECMAScript features into older browsers.
- dom0 10y ago
  The point of the quoted snipped seems more aimed at the "we lose the thread as an abstraction" part.
  - cestith 10y ago
    Good. It's good to lose the stateful thread as an abstraction. In the article we have someone promoting the use of a functional language on a functional programming site promoting the use of thread-lexical mutable variables to store state across procedure calls. The alternative the author dismisses is to swallow a return as an input. Something's not quite right here.
- oceanswave 10y ago
  Async/await, promises. I don't think 'callback hell' is not a problem anymore, not even to newcomers (with the right material).
- SomeCallMeTim 10y ago
  It's also a rather convoluted set of examples. If you're doing something in Node that takes nontrivial processing time (that doesn't just involve waiting for I/O), you're Doing It Wrong (tm). Since the premise of "callback hell" is outdated, the only remaining point is that if you perform complex/time consuming calculations in NodeJS, it slows down. If you want the most speed, or if you're going to be doing something like a Fibonacci calculation, you should write that (microservice) in Go instead. It's faster from the start (by 2x at least, probably a lot more if you're CPU bound), and GoRoutines can be spread across multiple threads, so a multi-CPU host can take advantage of all of its CPUs. Oh, and the per-GoRoutine overhead is only about 4K on a Linux host, last I checked. True that Haskell has a smaller overhead per thread, but considering the speed advantage, I think the Go server would still win big on latency for the number of threads that did actually fit in memory.
vikingcaffiene 10y ago
A lot of the readability problems with NodeJS the author mentions at the beginning of the article have been solved in numerous ways. Promise based work flows for instance allow one to define a step by step flow very similar to the counter examples provided. Packages like babel can expose things like yield and async/await which get us even closer. I'm not saying its ideal but it certainly mitigates the worst parts of the 'callback hell' problem pointed out.
deleted 10y ago
[deleted]
switchbak 10y ago
Another nitpick - most Java based web/app servers have used thread pooling (or similar approaches) for at least 10 years. Seems overly simplified to say these environments always "spawn a new thread".
- hyperpape 10y ago
  That saves you from thread spawning costs, but not thread overheads.
- aksx 10y ago
  but wouldn't you still require [Stack size] * [num concurrent connections] space? pooling just means that there won't be the cost of creating a new thread on all/most connections.
davidw 10y ago
> Node ... popularized the event-loop Tcl was doing event loops quite successfully in the late 90ies and was fairly popular, back in the day. These days, I'd use Erlang (Elixir). This is kind of ranty, but also makes me laugh: https://www.youtube.com/watch?v=bzkRVzciAZg https://www.youtube.com/watch?v=bzkRVzciAZg
- hyperpape 10y ago
  This is exactly what the word popularized means. It doesn't mean invented, it just means exposed it to a large number of people who hadn't previously encountered it. I don't know if you can claim definitively that Node introduced more people to event loops than any other technology, but it certainly is one major popularizer of the idea, and the one that's had the most impact in the past decade.
  - davidw 10y ago
    So basically people who knew nothing of what had come before, despite it being a fairly widespread technology. I think that's kind of proving the video's point.
    - hyperpape 10y ago
      People are constantly learning how to program, and they pick up ideas in different orders from different sources at different times in the history of a discipline. Every idea anyone has ever known was something they didn't know until they were introduced to it. The fact that you knew it first doesn't give you a reason to be snide.
- PeCaN 10y ago
  That and the “MongoDB Is Web Scale” always get a kick out of me. Server-side-JS has some weird ideas about performance.
guntars 10y ago
I guess if we're nitpicking, then here's another one: > Looking near the top of the output, we see that Haskell's run-time system was able to create 100,000 threads while only using 165 megabytes of memory. We are roughly consuming 1.65 kilobytes per thread. Those are not the same kind of threads that the author is talking about in the beginning of the article. Those a green threads and as such are multiplexed to much smaller amount of real system threads to do work in parallel. What that means is that they, for example, can't all make a system call at the same time. Go has the same issue.
- wyager 10y ago
  > What that means is that they, for example, can't all make a system call at the same time. Yes, they can. The Haskell IO manager knows how to handle this. http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask03...
  - guntars 10y ago
    That's true with a caveat. It knows how to handle IO syscalls on systems where something like "epoll" or "kqueue" is available which, to be fair, is majority of what a typical server does. In the general case waiting for a syscall to return will block the system thread and no other green thread is going to be able to run on it.
    - wyager 10y ago
      > In the general case waiting for a syscall to return will block the system thread and no other green thread is going to be able to run on it. The runtime will migrate pending green thread actions to other OS threads. I don't remember what happens if you have as many blocked FFI calls as OS threads. The runtime might spawn more if you're using RTS -N. If you have RTS -Nn, where n is a number, I imagine it does block.
    - platz 10y ago
      The GHC Haskell runtime supports preemtive scheduling of cooperative threads ("green threads"). In non-preemtive cooperative threading, threads yield to each other. However, when a thread goes into a syscall, it no longer has the control to yield. The only way to wake up from a syscall (and thus to decide wether another thread should be scheduled, inside the runtime, and thus to get preemtive scheduling), is to send a signal to the process that's blocked in the syscall; then the syscall gets interrupted with EINTR and the runtime can do its scheduling decision, and then resume the syscall if needed. This signal sending is done by setting up a periodic "timer signal" that sends SIGALRM to the process every 10 ms (by default). http://man7.org/linux/man-pages/man2/timer_create.2.html http://man7.org/linux/man-pages/man2/timer_create.2.html
jondubois 10y ago
>> The difference here is stark because in Node.JS's execution model, the moment it receives a request on the slow route, it must fully complete the computation for that route before it can begin on a new request. With this statement, the author acknowledges that the Node.js code in the slow route was not asynchronous. The test is therefore invalid; it's comparing apples and oranges. Node.js is more than capable of handling different requests asynchronously (regardless of whether they are fast or slow); if you have any kind of blocking or waiting around happening; then you're doing it wrong. I'm so tired of all the anti-Node.js propaganda; it's hurting people. If I walk into one more company where some zombie tells me that they're migrating away from Node.js because "the Node.js event loop starves the CPU", I'm going to have a stroke. In reality all Node.js 'starvation' problems can be solved with the 'cluster' module or the 'child_process' module. Since we've been talking a lot about 'Fake news' on Facebook recently. Maybe we should start talking about how fake news is affecting Hacker News. This anti-Node.js strain is particularly virulent.
spitfire 10y ago
It feels like this generation has never had to use Windows 3.1 Or maintain an event loop application long term. There are good reasons we went to thread based models - developer productivity and safety. Event loops are fine for toy demo's, or very carefully managed products (trading systems, NGINX) but not for use as general purpose hammers. Every single bit of extra friction and cognitive overhead costs you dearly a few years down the line. We scrambled away from this stuff as soon as we could, and there's no good reason to go back.
- wolfgang42 10y ago
  Having done programming with both threaded and event-looped systems, I think that event loops (when done well) cause less cognitive overhead. With threaded systems, I was constantly worrying about how things need to be locked and what happens if two things run simultaneously. Event-looped systems make the break points explicit, so I know precisely when other things might run. "Callback hell" is IMO a terrible way of doing event-loop systems, as the nesting can get confusing. For implicit event loops like Node, I strongly prefer the Promises approach (preferably with async/await sugar); for explicit event loops (I only have practical experience with Arduino, though I've also a passing acquaintance with the classic 69k Mac as well) I like to build a set of event-driven state machines with cooperative multitasking. If properly designed, these keep everything nicely separated so you can follow the logic without any trouble, while also avoiding the concurrency concerns of a threaded system.
  - tracker1 10y ago
    I switched to babel pretty early on precisely to be able to use async/await... I wrote several wrappers around other systems to make them work cleanly in that model. It's been exceedingly nice.
    - wolfgang42 10y ago
      I've been using babel to great effect on client-side apps which have to be transpiled/bundled anyway, but I've been avoiding it on the server side in an attempt to avoid the mental overhead of another item in the build toolchain. So far it hasn't been enough of an issue to warrant adding another tool, but I'm eagerly awaiting native async/await in NodeJS (scheduled for version 8 AFAIK).
jondubois 10y ago
This article is misleading. Here's the real problem: https://github.com/AndrewRademacher/fpco-article-examples/blob/master/concurrency-and-node/node-async/src/starvation-main.js#L22L32 https://github.com/AndrewRademacher/fpco-article-examples/bl... Anyone who understands JavaScript can see that the recursion invoked in the slow route is not asynchronous (each recursive invocation keeps piling onto the call stack without ever releasing it)! You'd have to use process.nextTick (or setTimeout) if you wanted to recurse asynchronously without spawning a new process... For these kinds of unusual, heavy computations, though, you'd be better off using the child_process module to spawn a new process and do the recursion inside that process so that it doesn't block the main event loop. This has nothing to do with starvation. Node.js just has a completely different approach to this kind of problem.
- wyager 10y ago
  > Maybe Haskell does some sort of automatic multi-threading behind the scenes - If so, I'm not sure that's a good thing GHC (the leading Haskell compiler) provides an extremely advanced green threading system with the runtime. http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask03... > I like the way it's done in Node.js - Explicitly. If you wanted to do it this way in Haskell, there are a number of monads that make it way more convenient than doing it in Node. Cont in particular can be used for cooperative concurrency. No one really uses these outside of niche cases, however, because threads are almost always a better abstraction.
  - jondubois 10y ago
    Maybe, Golang also has similar advanced multi-threading constructs. But I do a lot of REST API (and WebSocket) work and all of the workload that happens inside my Node.js program is extremely lightweight. If I need to perform some heavy computation, I will offload it to a separate child process - Node.js forces me to put that code in a separate file/module but I actually like this because it encourages separation of concerns. It feels very natural so I don't really need any other special constructs. I looked into goroutines a while ago; it looks cool, but I probably wouldn't use them much because I don't like the idea of having code from the same source file splitting off into multiple processes/threads; it makes is harder to read and reason about the code (this is a bit like what happens with multi-threaded code when you have mutexes all over the place). To me, this feature has the same utility value as the ability to define multiple classes per source file - Ok, that's cool, but is it a good idea to do that?
hitgeek 10y ago
is the author really just comparing single-core to multi-core? I didn't read any specs on the machine that ran the benchmarks, but assuming its multi-core, are the Haskell tests using all the cores, while node is only using 1? node is probably not the best choice for truly CPU bound operations, but you can sometimes get by using the native cluster module to spread work over multiple cores.
- tracker1 10y ago
  For a few things, I've spun off another process, and use a pool in order to constrain the number of processes actually running at once... did this to adapt a JS based scrypt module when I was running node in windows, and non of the "native" versions of scrypt in npm would even build correctly in windows (early 0.8 timeframe iirc).
tracker1 10y ago
I don't think this comparison is really fair at all... it seems to be cherry picked to point out what is already known to be a bad use case for node. In terms of the multiple async calls, Promises and async functions takes care of that, not to be confused with the reference to the `async` library. First, using clustering and memoization would improve the throughput a lot. I did something similar when adapting a JS based script library to be used in node, because I knew it would lock the main loop otherwise. Beyond this, cpu intensive work should be avoided in your service loop regardless. It's best distributed to an RPC/Worker pool. In terms of scale, node scales as well or better than a lot of frameworks, it's only that you will usually want to use similar techniques locally as well as remote. Another poor example is when you need millions of references in a single thread, Node will die spectacularly. That doesn't mean it shouldn't be used for many use cases, it only means that it's bad at some of them. I find that node is great as an intermediate/translation layer... your UI talks directly to node, tightly coupled.. then node can translate against backend databases or other services as a gatekeeper for your front end. It allows you to make the data the shape that is most convenient, with the least amount of disconnect of thought and approach. It's also pretty great for certain types of orchestration control and even in the proof of concept stages of applications. Doing a first version of almost anything I've tried in Node is usually much faster than alternative platforms. And often performs well enough to stick with it. Developer productivity is more important than absolute scale at the beginning, and if you have a plan to scale horizontally, you can do that for a while before you need to break off other optimizations.
- Scarbutt 10y ago
  Doing a first version of almost anything I've tried in Node is usually much faster than alternative platforms. Do you say this because of the libraries available for it? (curious, wanting to jump to node).
  - tracker1 10y ago
    I mean faster to get up and running... development time that is. Mostly, for me, because I'm doing front end work in JS, using mostly the same tooling npm, babel (though with webpack on front end now). It's just so much faster to get going if you're developing the full stack, and already in JS heavy land anyway. Not having to context switch for the backend is huge... being able to use a document/object/json database isn't as big of a boost but still nice. On the db side, I've been using the template wrappers so that I can write a simple query and it turns it into a parameterized query returning a promise. async function getRecords(baz) { return await sql.query` SELECT a, b FROM foo WHERE foo.bar = ${baz} `; } So, I still have to think about some SQL, but still usually better than trying to twist ORMs into shape. Overall, for the past 6 years or so (since 0.8) I've been using Node pretty heavily (moving from more C# on the backend) and really haven't missed it at all. Even though the core .net and more open-source stuff has been interesting... Managed to dockerize a few trivial .Net apps using the dotnet onbuild base containers. If you're using windows, the only gotchas are you need a C++ build environment (Visual C++ 2015 Build Tools, checking all options) and Python 2.7.x in order to build any binary modules... most of which now run without issue on windows, was a much bigger problem in 0.8-0.10 ...
stanislavb 10y ago
In regards of concurrency, I's suggest to have a look at Elixir. It's growing like weed and is offering the best programming experience you can find. Not kidding. Just try it.
ky3 10y ago
Previous comments on threaded vs event-loop concurrency abstractions are relevant: https://hn.algolia.com/?query=why%20events%20are%20a%20bad%20idea&sort=byPopularity&prefix=false&page=0&dateRange=all&type=story https://hn.algolia.com/?query=why%20events%20are%20a%20bad%2... https://hn.algolia.com/?query=why%20threads%20are%20a%20bad%20idea&sort=byPopularity&prefix=false&page=0&dateRange=all&type=story https://hn.algolia.com/?query=why%20threads%20are%20a%20bad%... https://hn.algolia.com/?query=threads%20vs%20events&sort=byPopularity&prefix=false&page=0&dateRange=all&type=story https://hn.algolia.com/?query=threads%20vs%20events&sort=byP...
z3t4 10y ago
lamda, anonymous functions are so popular in JS that it migt be a suprise that you can actually name your functions. Heck you can even use them like any object, pass them along, store them in lists, return a funtion from a fuction etc.
partycoder 10y ago
node is fast when the heaviest work is delegated to libuv or native modules (that are performant that is). If you require to do heavy work on v8, it slows down significantly. What would I call "heavy work"? e.g: compression, serialization, encryption, image processing... tasks that are bound by CPU and not only I/O. Usually you want to delegate that to a native module and not do that yourself in JavaScript. If you absolutely have to do it in JavaScript, then you need to make sure the task is not blocking the event loop. In order to play nicer with the event loop you inject something like setImmediate or process.nextTick after certain amount of time or iterations... otherwise you will starve other tasks in the loop, notably, I/O. node is also not a really good idea if you need a lot of interprocess communication. It is a very viable alternative, though.
spullara 10y ago
"Many web servers, for example achieve concurrency by creating a new thread for every connection. In most platforms, this comes at a substantial cost. The default stack size in Java 512KB, which means that if you have 1000 concurrent connections, your program will consume half a gigabyte of memory just for stack space. " As a WebLogic developer we fixed this in the late 90s but the Volano chat benchmark was still run for no apparent reason. Somehow everyone else didn't get the message until Netty was released and people started using it. Obviously what you want is multi-threaded execution with asynchronous I/O. Using node on multi-core systems just doesn't make a lot of sense as you end up having to duplicate your entire program on each core to get the full performance of the machine. Not unlike 512k/thread but much worse — especially if you cache anything locally in the process like template compilation, etc.
- seangrogg 10y ago
  If you're going to just duplicate your process across all the cores then yes, local caching becomes an issue. Which was solved with Redis. Back in 2009. Don't get me wrong, the fact that Node doesn't have a more efficient way of handling overhead on multicore machines is a drawback. But you pay for your abstractions. Nobody is going to argue that Node is a phenomenal solution for lightweight, multi-threaded execution. But most companies using Node seem to accept this and are fine with not utilizing 100% of their resources (hell, most don't even seem to know Node can spawn processes, in my experience). If they care they use a framework that meets their needs.
MrBuddyCasino 10y ago
So someone compared performance and programming model, and lo and behold, found Haskell to be superior. What might be more interesting: - what is the salary difference between a Node dev vs. a Haskeller? - is there a productivity difference? does the salary over- or under-compensate? - is correctness a core business concern? - if I need to hire 10 devs, can I do that?
jdc0589 10y ago
I'm getting sick of seeing this. Node wasn't intended for compute heavy workloads...ever...at any point...for any reason. This is like the 50th time someone has decided it was appropriate to point it out by generating Fibonacci numbers (among other things). Go watch the node.js presentation Ryan Dahl gave at JsConf 2009, he addresses this during that speech. His opinion on the "right way" to do concurrency is a little polarizing, but, quote: "the right way to do concurrency is to use a single thread and have an event loop. this requires that what you 'do' outside of IO waits not take very long".
eximius 10y ago
> However, Haskell doesn't impose an additional burden on the design of your software to accomplish that goal. giggles uncontrollably I like Haskell, but saying that it doesn't impose a design burden is incredibly misleading.
spion 10y ago
Here we go, a node version that uses a least-latency load balancer and doesn't exhibit the problem: https://github.com/spion/fpco-article-examples https://github.com/spion/fpco-article-examples Its an interesting benchmark, but it needs more work to give a more accurate picture. It would be nice if it: * used wrk to measure requests and latency percentiles * percentage of "slow" requests was tweakable * number of workers per core was tweakable Then we could generate a nice chart that shows latency percentiles as fn of % of slow requests and workers per core, and compare with Haskell.

129 points by ky3 10y ago

igl 10y ago

Comparing apples to oranges

lgas 10y ago
How so?
- edem 10y ago
  Node has no built-in concurrency just callbacks. The whole point is nonblocking io in node not multithreading.
  - Athas 10y ago
    Concurrency using event loops is still concurrency. Older cooperative concurrent systems used to work that way.
  - tracker1 10y ago
    Node does use threads for async io, it's just abstracted away from the main loop. The bigger issue, is the cpu bound code is a bad use case for Node, and it's known to be. There are options to run this type of code out of the main process though. You can scale node, via the same techniques you use to scale anything across servers, you just do it sooner with node in order to better utilize a larger server, or use multiple servers sooner. Node is great for just about any io bound workflow.
igl 10y ago
Downvoted ofc. To be more elaborate: Node never claimed to do multithreading or being good at parallel processing. The shocking discovery of this article is: 1) The Author knows little about JS. 2) Picking on a scripting language which has 2 weeks + 2 years of development vs a 25 year old monster that is the playground of the brightest minds in CS, is easy. Unfortunately the article did also not go into details of how the event loop works or shows how you can break out of the single thread with the tools that ARE available to you. I guess the idea was to write a hype article for Haskell. Here are some more ideas for the author: Comparing Haskell and C++ type systems. Comparing Haskell and Clojure functional purity and lazy evaluation. Comparing Haskell and Java deterministic parallelism.

aconz2 10y ago

The first part about comparing the callbacks in Javascript vs do notation in Haskell is super misleading. The do notation desguars to code that looks essentially identical to the Javascript version. Sugar is not a negligible consideration in system choice, but that kinda thing just bugs me.

hood_syntax 10y ago
That's a very fair point. I actually think in small doses the desugared Haskell looks better, but it gets ugly really quickly.
gkya 10y ago
Except its not really misleading. The code when you return later you can glance and read is better than that which looks like a landscape rotated counterclockwise.
efnx 10y ago
It desugars that way beacause of the nested structure of monadic sequencing, not because of threads or IO. We can distill the real argument down to "JavaScript must use nested callbacks for async. Haskell doesn't."

KirinDave 10y ago

On one thread, I am defending FP from critics who are unaware from the state of the art. EDIT: Just to make it clear early on, I agree with the article's conclusion that Nodejs is not as good at compute heavy workloads as Haskell. I simply object to any use of "the nested callback problem" as valid in 2016. It's an issue exclusively for legacy code and developers who take pride in writing outdated code. It seems only fair, then that I also should defend Javascript from people obviously unaware of the state of the art in pseudo-imperative programming. And by state of the art, I mean "has been around in some languages for 3+ years." The example: request('http://example.com/random-number', function(error, response1, body) { request('http://example.com/random-number', function(error, response2, body) { request('http://example.com/random-number', function(error, response3, body) { ... }); }); }); But modern Javascript (before you start, yes, it runs on every browser with preprocessing, which is normal for this ecosystem) would make it look more like this: // rp is a request promise, multiple options for creating them async function make3StaticRequests() { try { var res1 = await rp('http://example.com/random-number') var res2 = await rp('http://example.com/random-number') var res3 = await rp('http://example.com/random-number') // ... } catch(error) { // ... } } // And of course the promise library allows for many things // you'd like with applicative functors, like binding groups // of operations together and evaluating them all. function randomNumberPromise() { rp('http://example.com/random-number') } async function make3StaticRequests() { var [res1, res2, res3] = Promise.all([randomNumberPromise(), randomNumberPromise(), randomNumberPromise()]) // ... } I don't really understand why people feel comfortable writing up comparison articles without doing sufficient research into what they're comparing things to. That said, the articles point about large compute workloads starving other operations is very much true and a good example of what the weakness of V8 as a server-side programming environment brings.

spion 10y ago
For starvation there is also clustering, which can shift the load towards worker processes that aren't busy with cpu-intensive tasks, as well as simple modules such as `https://www.npmjs.com/package/process-pool` https://www.npmjs.com/package/process-pool` which can be used to offload (known) expensive tasks. While Haskell is truly better at concurrency (no need to serialise when passing messages, green threads yield not only at IO but also at memory allocations), that part of the comparison isn't very good. Spawning a cluster of NUMCORES threads using the built in cluster module would be an improvement.

ninjakeyboard 10y ago

Node has concurrency? :P

leshow 10y ago
i think you are confusing concurrency with parallelism.
tracker1 10y ago
Node uses a thread pool for async i/o flows, it's just this is abstracted away from you in terms of the main event loop. It's really an elegant model, and makes node a great fit for a LOT of use cases. Using the most broadly used dynamic language on the planet probably doesn't hurt as well.

reqres 10y ago

> Which leads to the 'callback hell' that we all know and hate. Part of the bill-of-goods we accept when using Node is that in exchange better time and space characteristics, we lose the thread as an abstraction. Perhaps my head has been stuck in javascript/node land for too long but I think accusations about javascript producing callback hell now seem a bit disingenuous even for relative novices to the language. It's 2016 and there are many well documented and widely adopted solutions arising from external libraries and developments in ECMAScript. Thanks to transpilers like Babel/Typescript we can even shoehorn these new ECMAScript features into older browsers.

dom0 10y ago
The point of the quoted snipped seems more aimed at the "we lose the thread as an abstraction" part.
- cestith 10y ago
  Good. It's good to lose the stateful thread as an abstraction. In the article we have someone promoting the use of a functional language on a functional programming site promoting the use of thread-lexical mutable variables to store state across procedure calls. The alternative the author dismisses is to swallow a return as an input. Something's not quite right here.
oceanswave 10y ago
Async/await, promises. I don't think 'callback hell' is not a problem anymore, not even to newcomers (with the right material).
SomeCallMeTim 10y ago
It's also a rather convoluted set of examples. If you're doing something in Node that takes nontrivial processing time (that doesn't just involve waiting for I/O), you're Doing It Wrong (tm). Since the premise of "callback hell" is outdated, the only remaining point is that if you perform complex/time consuming calculations in NodeJS, it slows down. If you want the most speed, or if you're going to be doing something like a Fibonacci calculation, you should write that (microservice) in Go instead. It's faster from the start (by 2x at least, probably a lot more if you're CPU bound), and GoRoutines can be spread across multiple threads, so a multi-CPU host can take advantage of all of its CPUs. Oh, and the per-GoRoutine overhead is only about 4K on a Linux host, last I checked. True that Haskell has a smaller overhead per thread, but considering the speed advantage, I think the Go server would still win big on latency for the number of threads that did actually fit in memory.

vikingcaffiene 10y ago

A lot of the readability problems with NodeJS the author mentions at the beginning of the article have been solved in numerous ways. Promise based work flows for instance allow one to define a step by step flow very similar to the counter examples provided. Packages like babel can expose things like yield and async/await which get us even closer. I'm not saying its ideal but it certainly mitigates the worst parts of the 'callback hell' problem pointed out.

deleted 10y ago

[deleted]

switchbak 10y ago

Another nitpick - most Java based web/app servers have used thread pooling (or similar approaches) for at least 10 years. Seems overly simplified to say these environments always "spawn a new thread".

hyperpape 10y ago
That saves you from thread spawning costs, but not thread overheads.
aksx 10y ago
but wouldn't you still require [Stack size] * [num concurrent connections] space? pooling just means that there won't be the cost of creating a new thread on all/most connections.

davidw 10y ago

> Node ... popularized the event-loop Tcl was doing event loops quite successfully in the late 90ies and was fairly popular, back in the day. These days, I'd use Erlang (Elixir). This is kind of ranty, but also makes me laugh: https://www.youtube.com/watch?v=bzkRVzciAZg https://www.youtube.com/watch?v=bzkRVzciAZg

hyperpape 10y ago
This is exactly what the word popularized means. It doesn't mean invented, it just means exposed it to a large number of people who hadn't previously encountered it. I don't know if you can claim definitively that Node introduced more people to event loops than any other technology, but it certainly is one major popularizer of the idea, and the one that's had the most impact in the past decade.
- davidw 10y ago
  So basically people who knew nothing of what had come before, despite it being a fairly widespread technology. I think that's kind of proving the video's point.
  - hyperpape 10y ago
    People are constantly learning how to program, and they pick up ideas in different orders from different sources at different times in the history of a discipline. Every idea anyone has ever known was something they didn't know until they were introduced to it. The fact that you knew it first doesn't give you a reason to be snide.
PeCaN 10y ago
That and the “MongoDB Is Web Scale” always get a kick out of me. Server-side-JS has some weird ideas about performance.

guntars 10y ago

I guess if we're nitpicking, then here's another one: > Looking near the top of the output, we see that Haskell's run-time system was able to create 100,000 threads while only using 165 megabytes of memory. We are roughly consuming 1.65 kilobytes per thread. Those are not the same kind of threads that the author is talking about in the beginning of the article. Those a green threads and as such are multiplexed to much smaller amount of real system threads to do work in parallel. What that means is that they, for example, can't all make a system call at the same time. Go has the same issue.

wyager 10y ago
> What that means is that they, for example, can't all make a system call at the same time. Yes, they can. The Haskell IO manager knows how to handle this. http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask03...
- guntars 10y ago
  That's true with a caveat. It knows how to handle IO syscalls on systems where something like "epoll" or "kqueue" is available which, to be fair, is majority of what a typical server does. In the general case waiting for a syscall to return will block the system thread and no other green thread is going to be able to run on it.
  - wyager 10y ago
    > In the general case waiting for a syscall to return will block the system thread and no other green thread is going to be able to run on it. The runtime will migrate pending green thread actions to other OS threads. I don't remember what happens if you have as many blocked FFI calls as OS threads. The runtime might spawn more if you're using RTS -N. If you have RTS -Nn, where n is a number, I imagine it does block.
  - platz 10y ago
    The GHC Haskell runtime supports preemtive scheduling of cooperative threads ("green threads"). In non-preemtive cooperative threading, threads yield to each other. However, when a thread goes into a syscall, it no longer has the control to yield. The only way to wake up from a syscall (and thus to decide wether another thread should be scheduled, inside the runtime, and thus to get preemtive scheduling), is to send a signal to the process that's blocked in the syscall; then the syscall gets interrupted with EINTR and the runtime can do its scheduling decision, and then resume the syscall if needed. This signal sending is done by setting up a periodic "timer signal" that sends SIGALRM to the process every 10 ms (by default). http://man7.org/linux/man-pages/man2/timer_create.2.html http://man7.org/linux/man-pages/man2/timer_create.2.html

jondubois 10y ago

>> The difference here is stark because in Node.JS's execution model, the moment it receives a request on the slow route, it must fully complete the computation for that route before it can begin on a new request. With this statement, the author acknowledges that the Node.js code in the slow route was not asynchronous. The test is therefore invalid; it's comparing apples and oranges. Node.js is more than capable of handling different requests asynchronously (regardless of whether they are fast or slow); if you have any kind of blocking or waiting around happening; then you're doing it wrong. I'm so tired of all the anti-Node.js propaganda; it's hurting people. If I walk into one more company where some zombie tells me that they're migrating away from Node.js because "the Node.js event loop starves the CPU", I'm going to have a stroke. In reality all Node.js 'starvation' problems can be solved with the 'cluster' module or the 'child_process' module. Since we've been talking a lot about 'Fake news' on Facebook recently. Maybe we should start talking about how fake news is affecting Hacker News. This anti-Node.js strain is particularly virulent.

spitfire 10y ago

It feels like this generation has never had to use Windows 3.1 Or maintain an event loop application long term. There are good reasons we went to thread based models - developer productivity and safety. Event loops are fine for toy demo's, or very carefully managed products (trading systems, NGINX) but not for use as general purpose hammers. Every single bit of extra friction and cognitive overhead costs you dearly a few years down the line. We scrambled away from this stuff as soon as we could, and there's no good reason to go back.

wolfgang42 10y ago
Having done programming with both threaded and event-looped systems, I think that event loops (when done well) cause less cognitive overhead. With threaded systems, I was constantly worrying about how things need to be locked and what happens if two things run simultaneously. Event-looped systems make the break points explicit, so I know precisely when other things might run. "Callback hell" is IMO a terrible way of doing event-loop systems, as the nesting can get confusing. For implicit event loops like Node, I strongly prefer the Promises approach (preferably with async/await sugar); for explicit event loops (I only have practical experience with Arduino, though I've also a passing acquaintance with the classic 69k Mac as well) I like to build a set of event-driven state machines with cooperative multitasking. If properly designed, these keep everything nicely separated so you can follow the logic without any trouble, while also avoiding the concurrency concerns of a threaded system.
- tracker1 10y ago
  I switched to babel pretty early on precisely to be able to use async/await... I wrote several wrappers around other systems to make them work cleanly in that model. It's been exceedingly nice.
  - wolfgang42 10y ago
    I've been using babel to great effect on client-side apps which have to be transpiled/bundled anyway, but I've been avoiding it on the server side in an attempt to avoid the mental overhead of another item in the build toolchain. So far it hasn't been enough of an issue to warrant adding another tool, but I'm eagerly awaiting native async/await in NodeJS (scheduled for version 8 AFAIK).

jondubois 10y ago

This article is misleading. Here's the real problem: https://github.com/AndrewRademacher/fpco-article-examples/blob/master/concurrency-and-node/node-async/src/starvation-main.js#L22L32 https://github.com/AndrewRademacher/fpco-article-examples/bl... Anyone who understands JavaScript can see that the recursion invoked in the slow route is not asynchronous (each recursive invocation keeps piling onto the call stack without ever releasing it)! You'd have to use process.nextTick (or setTimeout) if you wanted to recurse asynchronously without spawning a new process... For these kinds of unusual, heavy computations, though, you'd be better off using the child_process module to spawn a new process and do the recursion inside that process so that it doesn't block the main event loop. This has nothing to do with starvation. Node.js just has a completely different approach to this kind of problem.

wyager 10y ago
> Maybe Haskell does some sort of automatic multi-threading behind the scenes - If so, I'm not sure that's a good thing GHC (the leading Haskell compiler) provides an extremely advanced green threading system with the runtime. http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask03... > I like the way it's done in Node.js - Explicitly. If you wanted to do it this way in Haskell, there are a number of monads that make it way more convenient than doing it in Node. Cont in particular can be used for cooperative concurrency. No one really uses these outside of niche cases, however, because threads are almost always a better abstraction.
- jondubois 10y ago
  Maybe, Golang also has similar advanced multi-threading constructs. But I do a lot of REST API (and WebSocket) work and all of the workload that happens inside my Node.js program is extremely lightweight. If I need to perform some heavy computation, I will offload it to a separate child process - Node.js forces me to put that code in a separate file/module but I actually like this because it encourages separation of concerns. It feels very natural so I don't really need any other special constructs. I looked into goroutines a while ago; it looks cool, but I probably wouldn't use them much because I don't like the idea of having code from the same source file splitting off into multiple processes/threads; it makes is harder to read and reason about the code (this is a bit like what happens with multi-threaded code when you have mutexes all over the place). To me, this feature has the same utility value as the ability to define multiple classes per source file - Ok, that's cool, but is it a good idea to do that?

hitgeek 10y ago

is the author really just comparing single-core to multi-core? I didn't read any specs on the machine that ran the benchmarks, but assuming its multi-core, are the Haskell tests using all the cores, while node is only using 1? node is probably not the best choice for truly CPU bound operations, but you can sometimes get by using the native cluster module to spread work over multiple cores.

tracker1 10y ago
For a few things, I've spun off another process, and use a pool in order to constrain the number of processes actually running at once... did this to adapt a JS based scrypt module when I was running node in windows, and non of the "native" versions of scrypt in npm would even build correctly in windows (early 0.8 timeframe iirc).

tracker1 10y ago

I don't think this comparison is really fair at all... it seems to be cherry picked to point out what is already known to be a bad use case for node. In terms of the multiple async calls, Promises and async functions takes care of that, not to be confused with the reference to the `async` library. First, using clustering and memoization would improve the throughput a lot. I did something similar when adapting a JS based script library to be used in node, because I knew it would lock the main loop otherwise. Beyond this, cpu intensive work should be avoided in your service loop regardless. It's best distributed to an RPC/Worker pool. In terms of scale, node scales as well or better than a lot of frameworks, it's only that you will usually want to use similar techniques locally as well as remote. Another poor example is when you need millions of references in a single thread, Node will die spectacularly. That doesn't mean it shouldn't be used for many use cases, it only means that it's bad at some of them. I find that node is great as an intermediate/translation layer... your UI talks directly to node, tightly coupled.. then node can translate against backend databases or other services as a gatekeeper for your front end. It allows you to make the data the shape that is most convenient, with the least amount of disconnect of thought and approach. It's also pretty great for certain types of orchestration control and even in the proof of concept stages of applications. Doing a first version of almost anything I've tried in Node is usually much faster than alternative platforms. And often performs well enough to stick with it. Developer productivity is more important than absolute scale at the beginning, and if you have a plan to scale horizontally, you can do that for a while before you need to break off other optimizations.

Scarbutt 10y ago
Doing a first version of almost anything I've tried in Node is usually much faster than alternative platforms. Do you say this because of the libraries available for it? (curious, wanting to jump to node).
- tracker1 10y ago
  I mean faster to get up and running... development time that is. Mostly, for me, because I'm doing front end work in JS, using mostly the same tooling npm, babel (though with webpack on front end now). It's just so much faster to get going if you're developing the full stack, and already in JS heavy land anyway. Not having to context switch for the backend is huge... being able to use a document/object/json database isn't as big of a boost but still nice. On the db side, I've been using the template wrappers so that I can write a simple query and it turns it into a parameterized query returning a promise. async function getRecords(baz) { return await sql.query` SELECT a, b FROM foo WHERE foo.bar = ${baz} `; } So, I still have to think about some SQL, but still usually better than trying to twist ORMs into shape. Overall, for the past 6 years or so (since 0.8) I've been using Node pretty heavily (moving from more C# on the backend) and really haven't missed it at all. Even though the core .net and more open-source stuff has been interesting... Managed to dockerize a few trivial .Net apps using the dotnet onbuild base containers. If you're using windows, the only gotchas are you need a C++ build environment (Visual C++ 2015 Build Tools, checking all options) and Python 2.7.x in order to build any binary modules... most of which now run without issue on windows, was a much bigger problem in 0.8-0.10 ...

stanislavb 10y ago

In regards of concurrency, I's suggest to have a look at Elixir. It's growing like weed and is offering the best programming experience you can find. Not kidding. Just try it.

ky3 10y ago

Previous comments on threaded vs event-loop concurrency abstractions are relevant: https://hn.algolia.com/?query=why%20events%20are%20a%20bad%20idea&sort=byPopularity&prefix=false&page=0&dateRange=all&type=story https://hn.algolia.com/?query=why%20events%20are%20a%20bad%2... https://hn.algolia.com/?query=why%20threads%20are%20a%20bad%20idea&sort=byPopularity&prefix=false&page=0&dateRange=all&type=story https://hn.algolia.com/?query=why%20threads%20are%20a%20bad%... https://hn.algolia.com/?query=threads%20vs%20events&sort=byPopularity&prefix=false&page=0&dateRange=all&type=story https://hn.algolia.com/?query=threads%20vs%20events&sort=byP...

z3t4 10y ago

lamda, anonymous functions are so popular in JS that it migt be a suprise that you can actually name your functions. Heck you can even use them like any object, pass them along, store them in lists, return a funtion from a fuction etc.

partycoder 10y ago

node is fast when the heaviest work is delegated to libuv or native modules (that are performant that is). If you require to do heavy work on v8, it slows down significantly. What would I call "heavy work"? e.g: compression, serialization, encryption, image processing... tasks that are bound by CPU and not only I/O. Usually you want to delegate that to a native module and not do that yourself in JavaScript. If you absolutely have to do it in JavaScript, then you need to make sure the task is not blocking the event loop. In order to play nicer with the event loop you inject something like setImmediate or process.nextTick after certain amount of time or iterations... otherwise you will starve other tasks in the loop, notably, I/O. node is also not a really good idea if you need a lot of interprocess communication. It is a very viable alternative, though.

spullara 10y ago

"Many web servers, for example achieve concurrency by creating a new thread for every connection. In most platforms, this comes at a substantial cost. The default stack size in Java 512KB, which means that if you have 1000 concurrent connections, your program will consume half a gigabyte of memory just for stack space. " As a WebLogic developer we fixed this in the late 90s but the Volano chat benchmark was still run for no apparent reason. Somehow everyone else didn't get the message until Netty was released and people started using it. Obviously what you want is multi-threaded execution with asynchronous I/O. Using node on multi-core systems just doesn't make a lot of sense as you end up having to duplicate your entire program on each core to get the full performance of the machine. Not unlike 512k/thread but much worse — especially if you cache anything locally in the process like template compilation, etc.

seangrogg 10y ago
If you're going to just duplicate your process across all the cores then yes, local caching becomes an issue. Which was solved with Redis. Back in 2009. Don't get me wrong, the fact that Node doesn't have a more efficient way of handling overhead on multicore machines is a drawback. But you pay for your abstractions. Nobody is going to argue that Node is a phenomenal solution for lightweight, multi-threaded execution. But most companies using Node seem to accept this and are fine with not utilizing 100% of their resources (hell, most don't even seem to know Node can spawn processes, in my experience). If they care they use a framework that meets their needs.

MrBuddyCasino 10y ago

So someone compared performance and programming model, and lo and behold, found Haskell to be superior. What might be more interesting: - what is the salary difference between a Node dev vs. a Haskeller? - is there a productivity difference? does the salary over- or under-compensate? - is correctness a core business concern? - if I need to hire 10 devs, can I do that?

jdc0589 10y ago

I'm getting sick of seeing this. Node wasn't intended for compute heavy workloads...ever...at any point...for any reason. This is like the 50th time someone has decided it was appropriate to point it out by generating Fibonacci numbers (among other things). Go watch the node.js presentation Ryan Dahl gave at JsConf 2009, he addresses this during that speech. His opinion on the "right way" to do concurrency is a little polarizing, but, quote: "the right way to do concurrency is to use a single thread and have an event loop. this requires that what you 'do' outside of IO waits not take very long".

eximius 10y ago

> However, Haskell doesn't impose an additional burden on the design of your software to accomplish that goal. giggles uncontrollably I like Haskell, but saying that it doesn't impose a design burden is incredibly misleading.

spion 10y ago

Here we go, a node version that uses a least-latency load balancer and doesn't exhibit the problem: https://github.com/spion/fpco-article-examples https://github.com/spion/fpco-article-examples Its an interesting benchmark, but it needs more work to give a more accurate picture. It would be nice if it: * used wrk to measure requests and latency percentiles * percentage of "slow" requests was tweakable * number of workers per core was tweakable Then we could generate a nice chart that shows latency percentiles as fn of % of slow requests and workers per core, and compare with Haskell.