> Our vision is that send/expect should work according to the default
distributed-process semantics, but one ought to be allowed to vary the
semantics of channel-based communication (as opposed to actor-based)
according to what is relevant to the application. E.g. an application
ought to be able to give up reliability for better latency/throughput
on a channel-by-channel basis.
That pretty exciting. I will have to put aside some time to tryout Cloud Haskell on top of your ZeroMQ layer. I would love to see a simple example of how this would work with different reliability settings in a ping-pong example.