http://tinyurl.com/3q8tkxc

Haskell is great for web development because:

1. Writing

   Iterator<Foo> it = list1.iterator();
   ArrayList<Foo> list2 = new ArrayList<Foo>();
   while (it.hasNext()) list2.add(bar(it.next()));

is way more work than writing

   list2 = map bar list1

2. No null pointers. Tightly constrained side-effects. Static typing 
powerful enough to statically detect many common bugs at compile-time. 
Automated run-time testing tools such as QuickCheck.

3. Thread-safe by default. Concurrency and parallelism are almost 
trivial to implement. [Of course, making it actually *go faster* is 
never trivial...] Very low cost for using more threads. Technologies 
like STM banish race conditions, deadlock, livelock and world poverty.

4. Really easy to link to C for performance-critical sections.

5. Several Haskell web servers / application frameworks with very 
competitive performance. (Of course, only the favourable benchmarks are 
shown. Obviously.)



http://tinyurl.com/64bfdmv

Simon P. J. enumerating the various Haskell technologies for multi-core 
programming: sparks, threads, locks, transactions, parallel arrays...



http://tinyurl.com/678c9xo

Implementing Erlang's distributed processing model in Haskell. (This is 
a work in progress. I doubt it's production-ready yet - or any time soon.)

Notable by its absence is hot code update. Some commentators have noted 
that if you actually care about high availability, you'll be using 
multiple hot-spares anyway, and so long as you don't take down all 
systems at once, you can just take one offline, update it, put it back 
online, and move on to the next one.

Erlang's basic idea is that you have threads running on multiple 
hardware nodes, and they exchange messages. Well, that's not especially 
hard. You just need to define a way to convert the data you want to 
send/receive into raw binary for transit over the network.

Slightly more tricky is that if a remote process dies, you want to be 
notified about it. That just requires some sort of background process 
running on each node to generate the notifications. Likewise, Erlang 
lets you spawn new threads on remote nodes; that just means you need to 
send a message to the corresponding background thread on the target node 
asking it to spawn a thread.

Ah, but there's a snag: How do you send functions over the network?

That's really the bit they've solved here. The basic idea is that when 
you ask to send a function, what actually gets sent is a representation 
of the function's free variables [which need to be sendable too, of 
course], followed by the address of the machine code for that function.

All of which obviously fails spectacularly if sender and receiver aren't 
running the same version of the same program. ;-)

Actually, sending the machine code address requires modifications to the 
compiler (i.e., a way for Haskell code to look up what the hell its 
address actually *is*). Currently they've implemented a kludge using 
Template Haskell to look up the function name at compile-time and send 
that as a text string instead. Also currently you have to do some 
legwork yourself which will eventually become automatic (e.g., working 
out which functions need to be sendable, making a list of them, and 
telling the compiler to generate machine code for them).

Amusingly, using Amazon EC2 you can actually chuck a Haskell program 
onto 100 nodes, run it, and see how fast it goes. (Obviously no normal 
human actually has access to 100 physical machines.) The graph of 
runtime verses number of nodes looks very much like 1/x to me...

Post a reply to this message