Hacker News Reader

Comment by moomin | Hacker News Reader

The most obvious one has to be that it doesn't run on BEAM, and so isn't going to favour the "1000 thread" approaches of true OTP systems.

View on HN

Haskell threads are pretty lightweight - 1000 would certainly be no problem: http://stackoverflow.com/questions/1900165/how-long-does-it-...

It was fun creating 3M threads on my laptop back in the day. http://www.reddit.com/r/programming/comments/a4n7s/stackless... :) memories!

Are you familiar with Haskell's threading model (sparks) and making an assessment based on that, or is it an unbased claim? Haskell has no problems running millions of threads.

FYI, sparks are different from threads. Haskell has "forkIO" threads which are comparable to Erlang processes/go-routines (actually, they're cheaper than both since haskell allocates less stack for threads). Threads are what you want for concurrent programming (i.e., non-deterministic interleaving of behaviour, which with GHC can be run in either single-threaded or multi-threaded mode).

Sparks are for deterministic parallelism, the idea behind sparks is that you create a pool of sparks, each of which represent a small, finite bit of work that can be done in parallel.

In general sparks will represent a finite, deterministic amount of work, whereas threads represent a (potentially) infinite amount of non-deterministic work.

For anyone looking for an example, I suggest Chapter 24 of Real World Haskell [1]. The parallel stuff is about halfway down.

[1] http://book.realworldhaskell.org/read/concurrent-and-multico...

Also worth looking at "Parallel and Concurrent Programming in Haskell" http://chimera.labs.oreilly.com/books/1230000000929

Probably one of the best books on the topics (parallelism, concurrency, distributed programming) overall in addition to being a great Haskell resource.

I'm going to stand corrected on this one. Time to learn some more stuff, it seems.

Reply on news.ycombinator.com