r/haskell • u/RobertKentKrook • 1d ago

Distributed Haskell - A Small Survey

https://www.krook.dev/posts/distributed-haskell/post.html

Hi!

I recently finished my PhD thesis, which contains a couple of pages about distributed Haskell-work. It is by no means an exhaustive survey, as the covered systems (and to what extent they are covered) are chosen by their relevance to my thesis.

I turned the chapter into a blog post, which some of you may enjoy reading.

37 Upvotes

100% Upvoted

11 comments sorted by

5

u/stevana 1d ago

I find it a bit odd that in a language that pride itself for separating pure from side-effectful code the main library for doing distributed programming is CloudHaskell, where everything is in IO.

If you look at which distributed systems do best when tested with Jepsen, you notice that its the ones which put all non-determinism behind interfaces and implement the interfaces twice: first using real IO (for the production deployment) and second using in-memory datastructures (for testing), and then do property-based testing.

Usually Haskell programmers are good at these kind of tests against fakes, but in this domain some parts of the imperative community are ahead of us. Check out "deterministic simulation testing" by, e.g., FoundationDB (C++) or TigerBeetleDB (Zig).

8

u/RobertKentKrook 1d ago

I cannot address all your points, but I want to point out that Cloud Haskell is not the de-facto library for distributed programming. The implementation is alive in the `remote-process` package, but it is not something that everyone reaches for when they implement distributed programs.

My anecdotal experience is that distributed programs are generally written as stand-alone components, compiled and deployed separately from each other. This is not unlike how it is done in other languages. There is ongoing research into making frameworks that lets you implement multiple components at once, whereby you can rule out certain classes of errors such as deadlocks or data races. See HasChor: https://github.com/gshen42/HasChor

While not necessarily related to distributed programming, well-typed, IOG, and Quviq has done some cool work on testing concurrent IO computations: https://well-typed.com/blog/2025/10/an-introduction-to-io-sim/

3

u/dacydergoth 16h ago

Timewarp (University of Bath, UK) would be an interesting one to look into as it uses eventual consistency based on oldest known message in the system

2

u/LaurentRDC 1d ago

FYI the canonical implementation of Cloud Haskell today isn't `remote`, it's `distributed-process`

2

u/stevechy 14h ago

Those are great references, thank you! I should have read them before writing my reply.

→ More replies (1)

2

u/LaurentRDC 1d ago

I'm glad someone brought up deterministic simulation testing. `io-classes` and `io-sim` are criminally underrated.

Over the past year, I've been working on a Raft implementation in Haskell, with testiing via `io-sim`, and it has caught so many weird bugs. I'm going to write up a blog post about it soon, but you can check it out here: https://github.com/LaurentRDC/distributed-consensus

The key piece of design is that networking and persistence is abstracted out. Then, you can use Cloud Haskell for the networking portion if you so choose

2

u/RobertKentKrook 59m ago

It sounds very cool. I look forward to reading your post!

1

u/stevechy 20h ago

CloudHaskell as far as I can tell and based on the survey is mostly focused on providing message passing with some Erlang inspired utilities. So it could be good at building systems that are like ejabberd or RabbitMQ which I don't think would benefit as much from Jepsen style correctness.

Looking at FoundationDB's simulation testing if you wanted to implement the same thing in Haskell the easiest way would probably use the IO monad. Based on https://pierrezemb.fr/posts/diving-into-foundationdb-simulation/#single-threaded-time-travel-the-event-loop and https://github.com/apple/foundationdb/blob/main/design/coroutines.md C++ coroutines are used to store the stack state. Haskell's lightweight threads could be used to store the stack state. Also with Haskell it would be easier to ensure that proceses/threads cannot interfere with each other between simulation steps.

To do this in a pure immutable way could be interesting in that you could get easier backtracking and history tracking. Haskell has some techniques like free monads and continuation monads to help with this but it's not essential to that type of testing.

4

u/Pope4u 1d ago edited 1d ago

Nice work, especially on Cloud Haskell