Facilitating Cloud Haskell use and development

#1

Hey everyone,

Cloud Haskell is a domain-specific language for developing distributed systems using the Actor model popularized by Erlang.

A suite of packages implementing Cloud Haskell ideas exist, such as distributed-process. These repositories are stored in the haskell-distributed organization on GitHub.

I want to ask the community: how can we make it easier for you to use or contribute to Cloud Haskell?

For example, on my side, reworking the organization structure would help in maintaining the >30 relevant packages. If you have comments about this, join the discussion here.

20 Likes
Towards an actor framework for Haskell
#2

thank you for moving this forward!

3 Likes
#3

Someone asked on GitHub what is the motivation for me to dedicate time to Cloud Haskell.

I initially volunteered to help maintain Cloud Haskell because I read the original paper and started playing with it. I thought it was so cool that I am basing some of the backend of my startup on it.

The key motivation to use Cloud Haskell for us is the idea of digital twins.
A digital twin is a process running at the edge of the cloud which mirrors something physical (e.g. an IoT device, or a physical person). Then, backend systems only interact with the digital twins, rather than directly with the real-world.

Using digital twins has a ton of advantages; most importantly for us, it allows to incorporate predictive analytics closer to the source of the data.

This isn’t a new idea; Tesla Energy uses this architecture to aggregate its Powerwalls into a virtual power plant in California via Akka.

As you can imagine, Cloud Haskell is perfectly suited to supervise and manage digital twin processes running in the cloud.

8 Likes
#4

This isn’t a new idea […]

Now I remember: NASA is probably the pioneer of digital twins for their space probes, but for a different purpose - before uploading the latest batch of instructions to the real probe, they first run them on the virtual one as a safety check!

4 Likes
#5

The typed-session is a communication protocol framework that statically checks the correctness of communication semantics and allows multi-role communication. I am currently writing its usage documentation. I am curious whether it can be integrated with Cloud Haskell.
Effects of typed-session:

more example code

4 Likes
#6

That looks really cool!

The clever design behind the implementation of Cloud Haskell is that messaging is completely decoupled from how the networking is done. You write programs in the Cloud Haskell DSL that is agnostic to the particular communication protocol.

There’s a lot of documentation about this on the haskell-distributed website. You can write your own networking layer for Cloud Haskell today based on typed-session.

6 Likes
#7

I am very interested in Cloud Haskell, and am also looking for paid work as a developer as I am being laid off from my current job. Is there a list of companies available that are using and/or contributing to Cloud Haskell?

#8

Sorry to hear you were laid off.

I would love to assemble a list of entities that use Cloud Haskell. However, since maintenance was minimal for a few years, I suspect that there are very few, if any, production workloads based on Cloud Haskell today.

Outside of paid roles, I know one of the active maintainers uses Cloud Haskell for high-performance computing workloads.

Maybe someone on Discourse knows more?

#9

I think for one it would be good to increase visibility with blog posts / etc, I have found the entire ecosystem to be somewhat opaque and not very discoverable - also, did you talk to the choreographic programming people? (Cf. HasChor) They do some really interesting stuff and it might be a good fit for abstracting over cloud haskell (just a hunch)

#10

I have not spoken to experts in choreographic programming yet.
I am vaguely familiar with it (via the Haskell Interlude podcast!) and I think it’s fascinating.

There are interesting proposals on the distributed-process wiki about future developments. You can read about it here, but in brief Cloud Haskell may evolve into the following structure:

  1. Networking layer – how to send bytes from one process to another, whether these processes are on the same nodes or different nations. This layer already exists via the network-transport-* packages;
  2. Messaging layer – how to send Haskell datatypes from one process to another, while preserving type safety. This layer involves typed channels and serialization;
  3. Application layer – how are typed channels used? Currently only the Actor model is supported

At this time, 2. and 3. are rolled into one (in distributed-process), but it doesn’t have to be this way. 1. and 2. could form a nice foundation for other distributed programming paradigms.

1 Like