If you're looking for a project to take on, I would suggest starting with the following: A high-level, type-safe AMQP client written in 100% Haskell, which provides a clean way of handling hundreds of unique message types. Then it would be possible to hook it up to any AMQP broker (most likely RabbitMQ). There are logical steps beyond the above (an embedded Haskell broker), but the above project is far from trivial. And the main undertaking, I think, consists not in coding to the spec (for which there is some help; a JSON representation of the AMQP specification can be processed and used to emit language-specific code), but in finding a design that works well in Haskell. Regards, John On Jan 8, 2009, at 1:16 PM, Creighton Hogg wrote:

On Thu, Jan 8, 2009 at 2:02 PM, John A. De Goes wrote:

...

On Jan 8, 2009, at 12:56 PM, Tim Newsham wrote:

...

You replied to someone discussing using Haskell at a CDN to implement things like web servers by saying that Haskell wasn't suitable for the task.

That is incorrect. I replied to Achim's message asking for elaboration on Haskell's unsuitability. It was a convenient point to discuss Haskell's networking deficiencies.

Part of the problem I'm having with this discussion, though, is that it's still not clear to me what critical features are lacking. I know you've said Haskell doesn't have anything quite like the Erlang OTP library, but that doesn't really help me much. I've only looked a little at OTP & I don't think I understand what you get from its behaviors that you don't get from Control.Concurrent + mtl, i.e. various forms of state & error handling independent of the concurrency underneath.

Can you elucidate a bit more? I don't want the conversation to degenerate.