[rektide]

Are they also in Haskell as in Erlang pre-emptable by the runtime?

There's certainly some cost in this design decision, more context that has to be swapped in and out and more state kept, but it's important capability to allow blind design & use- think Node, where everyone has to keep re-iterating how important it is to keep yielding to the event loop, to not do a lot of CPU work in a handler: irrelevant in Erlang world- in spite of the threading model not being OS threads, Erlang is happy to drop your lightweight thread on the fly when it sees fit.

[rdtsc]

> irrelevant in Erlang world

Exactly. That is a subtle distinction but for cases where responsiveness and low latency is important that is key. Another thing Erlang has is isolation of process heaps. If one process crashes, it won't affect others. No shared data structures between processes. It all goes to fault tolerance but also a major win for a completely concurrent garbage collection.

[masklinn]

> If one process crashes, it won't affect others.

Unless they're linking or monitoring one another, an other important property of tolerant and distributed system.

[rdtsc]

But that is on purpose. Sometimes you do want that. In other words they are explicitly set up to monitor/link each other.

[masklinn]

> But that is on purpose.

Indeed, but I was pointing it out because it's important to be able to do it.

[burntsushi]

> Are they also in Haskell as in Erlang pre-emptable by the runtime?

Yes. [1]

[1] - http://www.haskell.org/ghc/docs/latest/html/libraries/base/C...