Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cloud Haskell

haskell-distributed.github.io

Post reply on HN
Print view View original

11–20 of 32 posts

Re: Cloud Haskell

#11

Post by moomin »

platz wrote: post #2

If Cloud Haskell is going to reference "Erlang-style concurrent and distributed programming" and the Open Telecom Platform (OTP), I think it's warranted on the site to also see a comparison of what, if any, differences there are between the two in philosophy or differences in the Cloud Haskell's interpretation of those two things. Will some features be prioritized over others?

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.

Re: Cloud Haskell

#12

Post by njs12345 »

moomin wrote: post #11
platz wrote: post #2

If Cloud Haskell is going to reference "Erlang-style concurrent and distributed programming" and the Open Telecom Platform (OTP), I think it's warranted on the site to also see a comparison of what, if any, differences there are between the two in philosophy or differences in the Cloud Haskell's interpretation of those two things. Will some features be prioritized over others?

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.

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

Re: Cloud Haskell

#13

Post by stingraycharles »

moomin wrote: post #11
platz wrote: post #2

If Cloud Haskell is going to reference "Erlang-style concurrent and distributed programming" and the Open Telecom Platform (OTP), I think it's warranted on the site to also see a comparison of what, if any, differences there are between the two in philosophy or differences in the Cloud Haskell's interpretation of those two things. Will some features be prioritized over others?

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.

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.

Re: Cloud Haskell

#14

Post by merijnv »

stingraycharles wrote: post #13
moomin wrote: post #11

Earlier quoted context omitted.

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.

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.

Re: Cloud Haskell

#16

Post by flippant »

merijnv wrote: post #14
stingraycharles wrote: post #13

Earlier quoted context omitted.

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 p…

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...

Re: Cloud Haskell

#18

Post by dons »

njs12345 wrote: post #12
moomin wrote: post #11

Earlier quoted context omitted.

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.

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!

Re: Cloud Haskell

#19

Post by doublec »

flippant wrote: post #16
merijnv wrote: post #14

Earlier quoted context omitted.

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 p…

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

Re: Cloud Haskell

#20

Post by tel »

fenollp wrote: post #9
flippant wrote: post #7

Earlier quoted context omitted.

The obvious advantage is typed channels. http://haskell-distributed.github.io/documentation.html#type...

You can typecheck your had hoc Erlang protocols using Concuerror and Dialyzer

Dialyzer is nice, no doubt! But to compare it to Haskell's typing is disingenuous at best. Success typing captures far less information and maintains far fewer invariants.
Post reply on HN