|
|
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
|
|