
There's a JavaScript binding to Java, and there's a Java binding to Erlang, so nothing's stopping you from using JavaScript nodes in a distributed fashion -- if you have a weird obsession with proving that JavaScript is well-suited for every task. But really, what's the point? FFI code is fragile, often uncompilable and unsupported, and doesn't observe the idioms of Haskell nor take advantage of its powerful language features. Rather than coding through FFI, a messaging application is better off written in 100% Erlang, because the libraries are native there and so confer all the benefits unique to native libraries. You can indeed fit a square peg in a round hole, if you pound hard enough. That doesn't mean it's a good thing to do. Here's hoping someone develops a native messaging framework for Haskell, which is the equal of RabbitMQ. Regards, John On Jan 8, 2009, at 11:06 AM, Don Stewart wrote:
wchogg:
On Thu, Jan 8, 2009 at 8:32 AM, John A. De Goes
wrote: Haskell's networking support is very rudimentary. Erlang's is quite sophisticated. For network intensive applications, especially those requiring messaging, fault-tolerance, distribution, and so forth, there's no doubt that Erlang is a more productive choice.
Not because of the language, per se, but because of all the stuff that is packaged with it, or available for it.
Now I understand that there aren't(?) any Haskell implementations that can act as distributed nodes the way the Erlang implementation can, but I'm not familiar enough with Erlang to understand what it has for networking that the Haskell network packages don't have. Could you explain a bit further? I've been thinking a lot about network programming anyway lately & am looking for library opportunities.
Note that there even exists an FFI binding to Erlang for Haskell, so that Haskell nodes can seamlessly interact with other nodes speaking Erlang's protocol format.
There's nothing stopping you using Haskell nodes in a distributed fashion, and indeed there are groups doing this.
-- Don