Erlang vs. Haskell (was Re: [Haskell-cafe] binary IO)
joelr1 at gmail.com
Wed Dec 28 08:46:22 EST 2005
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.
More information about the Haskell-Cafe