I was interested in the latest use of Erlang for Comet by Facebook. However, thinking further about it, I wonder how the HTTP connections are typically being implemented (on Linux, say)? Erlang solves the problem of having lots of threads listening, but I am guessing it does not solve the problem of having lots of connections? Is there one thread listening to a network adapter, distributing the packages to the "virtual" connections? Or does the OS spawn a thread for every Connection it creates (presumably in some arcane C implementation)?
Maybe for the comet problem it would make more sense to optimize at that point, ie only spawn threads on incoming data? Erlang might still come in handy, depending on the number of concurrent messages, but perhaps not be the killer app it looks to be?
The SMP Erlang VM (as of Erlang/OTP R11B, R12B highly recommended) runs, by default, one process scheduler per CPU. So on a dual-core machine you can have two sockets being read from/written to simultaneously. Erlang allows you to program to a very simple model of one Erlang process per socket, with the VM using select/epoll/kqueue/etc to determine which processes have incoming data and are thus runnable.
Native processes use a lot of resources on most operating systems, so you can't use a process-per-socket model. So many web servers use a pool of processes/threads and queue up incoming requests that exceed that limit. Others use relatively few processes and use epoll/kqueue/etc directly.