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?
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.
Probably one of the best books on the topics (parallelism, concurrency, distributed programming) overall in addition to being a great Haskell resource.
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.
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:
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.
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.
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.
Ah take the stillborn academic wasteland of a language, and apply it to the devtard fad of the day - the cloud. And this is the product.
Meanwhile, back on the BEAM, we have a proper platform and a commercially proven solution.
Haskell is not a technology in search of a problem, it is a waxy tech lost in a room in an academic hall, withh the dust falling upon it.
Are you a real person or just a troll? Your other comment today insults feminists as "femtards", and now you call people who interact with cloud platforms "devtards." There are many respected "cloud" companies with employees who've worked on a large variety of difficult problems and contributed to both open-source communities and the field of computing as a whole.
Grow up and actually write something that's more than a paragraph-long ad hominem attack. It might be a good exercise to get rid of that insecurity that's probably causing this need to call others some form of "tards."
WRT the actual post: This is a neat idea. If nothing else it might help expose more people to Haskell.
31 comments
[ 3.9 ms ] story [ 74.5 ms ] threadSparks 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.
[1] http://book.realworldhaskell.org/read/concurrent-and-multico...
https://github.com/haskell-distributed
Other than get to use Haskell...
http://haskell-distributed.github.io/documentation.html#type...
[1]: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
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...
I was wonder, how well haskel does in that area...
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.
I know of about 20 companies with Haskell deployments and no one has regretted the move.
Grow up and actually write something that's more than a paragraph-long ad hominem attack. It might be a good exercise to get rid of that insecurity that's probably causing this need to call others some form of "tards."
WRT the actual post: This is a neat idea. If nothing else it might help expose more people to Haskell.