Cloud Haskell | Hacker News Reader

Cloud Haskell

haskell-distributed.github.io

104 pointsflippant29 comments

For those that might be scared by the fact that the "Recent Activity" list on the homepage hasn't been updated in a while: never fear, it's still under active development:

https://github.com/haskell-distributed

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

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.

Cloud Haskell has seen a lot of work by a lot of folks, but it's important to remind folks that it's not meant to serve every possible workload, nor is it necessarily the ultimate design for distributed compute in Haskell. It's good for some things, but not everything.

But if anyone was wondering "Can I do Actor Model / Microservices in Haskell" the answer is yes.

Any idea when GHC 7.10's static pointers will be supported?

Static pointers aren't all that usable in 7.10. I wouldn't be surprised if they waited for 7.12.

What advantages it bring over Erlang/Elixir OTP ?

Other than get to use Haskell...

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

Haskell's types are used for a lot more than type-checking.

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.

Faster and less memory intensive[1] and has a type system.

[1]: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

Hummm...

I do agree that Haskell will be faster and less memory intensive than erlang, but this benchmark is not really significant...

I am not going to use erlang to write a mandelbrot...

Yeah, it could well be that you just care about latency hiding on e.g. network services. For that raw compute and memory is much less important than having a reasonable thread scheduler and cheap threads.

Exactly my point :)

I was wonder, how well haskel does in that area...

I guess Haskell finally made it.

I'm currently leading an effort to introduce Haskell in a mid-size Chicago company that was historically a Ruby shop.

Haskell has past "made it". At this point it's an embarrassment of riches. It's easy to get tied up trying to figure out which great Haskell library to use when the fact often is that any one of them is usually better than the leaders in most other languages.

What has been your experience using Haskell been like in production? I'd love to use it for my next project

Very positive, and I'm not alone on this.

I know of about 20 companies with Haskell deployments and no one has regretted the move.

Reply on news.ycombinator.com