Group items tagged

Since I wrote a bittorrent client in both Erlang and Haskell, etorrent and combinatorrent respectively, I decided to put up some bait. This might erupt in a language war and “My language is better than yours”, but I feel I am obligated to write something subjective. Here is to woes of programming in Haskell and Erlang.Neither Haskell, nor Erlang was a first language for me. I have programmed serious programs in C, Standard ML, Ocaml, Python, Java and Perl; tasted the cake of Go, Javascript, Scheme and Ruby; and has written substantial stuff in Coq and Twelf. I love static type systems, a bias that will rear its ugly head and breathe fire.I have written Haskell code seriously since 2005 and Erlang code seriously since 2007. I have programmed functionally since 1997 or so. My toilet reading currently is “Categories for the working mathematician” by Mac Lane. Ten years ago it was “ML for the working programmer” by Paulson.Enough about me.

Erlang allows for massively scalable concurrency, often with millions of lightweight, thread-like components known as actors. Unfortunately, using Erlang requires rewriting all of your legacy code into a rather esoteric language. But there are other options, such as the little known CCR platform that was developed by .NET's robotics department. Actor based languages such as Erlang are able to achieve high degrees of parallelism by using the Actor model. Under this model the fundamental unit of concurrency is not a thread or fiber, but rather something much smaller. Known as a "process" in Erlang, each unit of concurrency has a base overhead of about 1200 bytes on a 32-bit system. By comparison, a thread on the Windows operating system defaults to 1 MB just for the stack, additional space is also needed for bookkeeping and thread local storage. Because they are so lightweight, an application can spawn literally millions of processes simultaneously.