[Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical
Haskell job in New York]
John A. De Goes
john at n-brain.net
Fri Jan 9 09:46:56 EST 2009
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.
On Jan 8, 2009, at 1:16 PM, Creighton Hogg wrote:
> On Thu, Jan 8, 2009 at 2:02 PM, John A. De Goes <john at n-brain.net>
>> On Jan 8, 2009, at 12:56 PM, Tim Newsham wrote:
>>> You replied to someone discussing using Haskell at a CDN to
>>> 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
>> 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
> Can you elucidate a bit more? I don't want the conversation to
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe