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.
Cloud Haskell
21–30 of 32 posts
Re: Cloud Haskell
#22I guess Haskell finally made it.
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.
Re: Cloud Haskell
#23Earlier quoted context omitted.
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
#24Re: Cloud Haskell
#25I 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.
Re: Cloud Haskell
#26I 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.
Re: Cloud Haskell
#27Ah 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.
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.
Re: Cloud Haskell
#28Earlier quoted context omitted.
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
I know of about 20 companies with Haskell deployments and no one has regretted the move.
Re: Cloud Haskell
#29If 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
#30What advantages it bring over Erlang/Elixir OTP ? Other than get to use Haskell...
Faster and less memory intensive[1] and has a type system. [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...