0MQ and Haskell

Ever since I heard the FLOSS weekly episode on 0MQ I’ve been looking for a reason to take a look at it. Well, to hell with reason, I’ll have a first look without any specific goal in mind.

I found a simple introduction to it in Nicholas Piël’s post ZeroMQ an introduction. The only issue was that it was based on Python, and Python2 at that. So here are my attempts at translating two of the clients to Haskell (using zeromq-haskell).


Here’s the client in Python3 first:

And here in Haskell:


In Python3:


Two comments on the Haskell code here:

  • I’m not sure why, but the Haskell client dies after receiving just a few messages (they are properly filtered though).
  • The API for subscribe is a bit strange, it would make more sense if it took a ByteString rather than a String.


I’m not sure why, but the Haskell client dies after receiving just a few messages (they are properly filtered though).

Someone should write a blog post where they successfully debug a problem like this. That would be a pretty interesting display of real world Haskell and its development tools.

Mark Wotton

Xavier Lange and I have been working on a pure Haskell implementation of 0MQ too. I’ve been using the binding pretty heavily, but there are some things you can’t do directly with it. Still, it’s exciting technology, I’ve put a large part of ninjablocks.com’s back end onto it (albeit using ruby) and I’m looking forward to shifting more of it to Haskell.

http://github.com/ninjablocks/zmqhs (at least until Xavier pulls my changes in)


@anonymous, indeed, I’d love reading something like that too. Have you started writing it yet? ;)


@Mark, Cool, do you already have some numbers comparing your pure Haskell implementation against the FFI implementation in zeromq?


@Magnus not yet, it’s still at a very early stage. We can successfully receive and send messages, but we haven’t got proper support for the different socket types. I’m a bit torn here, actually - the C implementation uses a state machine to model the allowable patterns (ie, a REQ socket has to send then receive in strict alternation, and vice-versa for a REP socket) - it feels like something we ought to be able to model in the type system in Haskell.

Interestingly, I’ve found it changes the way I write C much more than the way I write Haskell. The appeal for Haskell is in being able to interoperate with other runtimes, i think: if you just wanted intra-process coordination, you already have cheap threads and MVar/TVar/STM etc.


You know forM_ = flip mapM_ right, just trying to spare an import?

Leave a comment