We've done some benchmarking against Erlang. We're in the same ballpark. Erlang beats us on throughput for small messages but we know why we have higher overhead there and we know how to fix it. But actually the fact that we understand it and know how to fix it means it's not really our top priority. If it's an issue for anyone then they can get us to work on it, it shouldn't be too hard.

As I say in the post, we think it is ready for serious experiments. That doesn't mean you should immediately base your next mission critical project on it.

So we don't claim it is polished or that you will have no issues, but we think it's a very promising technology and we are keen to help any customers that are interested in using it. There's lots of directions in which we could improve it, depending on what people need. And of course it's also open source so if you want to hack on it yourself that's also great.

Their gut-feeling is that their bullet-proof cloud project synergizes the resources, while breakout improvement prioritizes the key people from the get-go. Their perspective empowers the thought leader within the community, whereas their verifiable cloud footprints transfer the cloud standard-setters. They’ve got to build a bullet-proof cloud convergence; this is why the group 24/7 delivers. The thought leader pre-prepares their versatile, controlled, cloud industries, and a strong self-awareness cautiously targets the cloud resources. So cloud development models boost the client-oriented cloudportunity, while the community-wide cloudnovation promotes the key people. And because of this, the enablers learn leveraged and/or high-performing cloud interdependencies. At the same time, the partners 200% whiteboard their growing on-boarding cloud processes. So as a result, the cloud developers engineer a full-scale cloud value creation cloud.

The first time I heard the term Cloud Haskell, I had a very similar response! Oh no, marketing buzzword!

The fun thing is that we now have a little bit of justification for the "cloud" buzzword, we've got a new backend specifically for working with a cloud service (Azure), and backends for EC2 etc should also be straightforward. This is quite nice really because while not many people have access to a cluster, anyone can now rent one for a few hours.

I'm perfectly comfortable with calling your Azure implementation a cloud backend, much less so with the Cloud Haskell name in general. The model you're implementing proved its worth in Erlang decades before "cloud computing".

Naming aside, I'm extremely exited about the project and its recent progress.

The SPJ talk was fantastic, as usual. The method of serializing a data structure, along with its deserialization routine is very impressive. Also, I always enjoy SPJ's palpable and infectious enthusiasm.

It would also be interesting to see how this compares to the Hadoop stack, which is the de-facto platform for doing cloud computing. I guess this could function as a base for building a Hadoop-like stack in Haskell? One of the awesome things they do is just distribute the entire code across the platform (as copying the code is cheap, and copying the data generally isn't cheap).

So one thing I love about erlang is the way epmd and DNS are used to create ad-hoc clusters. I think Epstein's initial Cloud Haskell had two options: config-file based clusters, or multicast discovery, and I haven't seen much that has differed since then. What I'd love is to be able to have an interface as simple as "send a message to (dns_name, registered_process_name)". Maybe the message will be sent, maybe not. I haven't seen any Cloud Haskell implementation where it would even be possible to write something like this. Can this implementation support ad-hoc DNS-based networks?

An important design decision of the reimplementation is to support multiple network layers and multiple backends. The SimpleLocalnet backend at the moment supports multicast based node discovery, and the Azure backend allows to discover Azure machines by querying the Microsoft Azure API. What you are suggesting is not currently supported, but it would certainly be possible to develop a backend (even as completely separate package) that implementations such functionality.