Erlang vs. Haskell (was Re: [Haskell-cafe] binary IO)

[Joel Reymont]

On Dec 28, 2005, at 1:05 PM, Sebastian Sylvan wrote:
> How does this work if you remove the file-reading? I mean just putting
> the file on a small TCP/IP file server with some simulated latency and
> bandwidth limitation, and then connecting to that in each thread?

This is probably the way to go but I don't have a a corresponding  
Haskell repro case.

This is what my application does, basically, and I'm getting timeouts  
there. Which is the reason that I created the file-based test in the  
first place. The results from the two seemed very similar, i.e.  
timeouts in both versions.

I will know how the full-blown Erlang app behaves today. 3 months of  
Haskell vs. 3 days of Erlang. There's the right tool for every job  
and while Haskell code could be tweaked to be on par with Erlang  
doing this will be missing the point.

Using Haskell for this networking app forced me to focus on all the  
issues _but_ the business logic. Type constraints, binary IO and  
serialization, minimizing memory use and fighting laziness, timers,  
tweaking concurrency and setting up message channels, you name it.

There are no type constraints to take care of with Erlang since it's  
dynamically typed. It's also strict and has excellent support for  
binary IO, serialization, timers and so on. All this is a given. You  
can just assume that doing it the most natural way is "doing the  
right thing" and can focus on the business logic.

The Erlang VM and distribution has been tweaked and polished to no  
end by Ericsson with the single-minded networking focus. It's a  
specialist language designed for high-concurrency, fault-tolerance,  
scalability and protocol processing.

It's also a pure functional language and it doesn't even have the IO  
monad. Alternatively, you could say that the IO monad is hidden away  
in the built-in library functions. You still cannot mutate a  
variable, you are always copying.

You can probably try to do all sorts of things with Erlang (look at  
Wings 3D) but I would probably just stick to high concurrency and  
networking apps. I would like to see if Yampa (and Frag) can be more  
transparently done in Erlang but that's because I find Yampa  
extremely complicated. Otherwise, as you try to do things that Erlang  
probably wasn't optimized for, you will face limitations just like I  
did with Haskell.

There's not a lot of business logic to focus on in my app. I just had  
to add a thin serialization veneer (http://wagerlabs.com/erlang/ 
pickle.erl) that implements the pickler combinators and ... I was  
done. ZLib compression is built into the Erlang distribution and  
since the Erlang FFI makes me cringe I implemented the custom SSL  
encryption as a single-threaded UDP server in about 170 lines of C.  
This is how i was able to finish 30 times faster.

	Joel

--
http://wagerlabs.com/