Lambda the Ultimate

I'd like to preface this by saying that I'm far less scholarly than the regular posters here so my opinion doesn't necessarily count for much.

In any case an experience like this comes as little surprise, in fact it's almost a perfect expression of the same argument often used for Lisp advocacy. "Use a tool that can be adapted to the job". Erlang was written especially to ease the pain of massive concurrency and failover. Using it for what it was built for doesn't devalue Lisp in any way :)

Of course a project like this can be done in Lisp but if it's more natural to do it in a more domain friendly language than well- there's nothing wrong with that.

As for me I'm pretty keen on Erlang, I've been exploring it for the past several weeks with an eye toward some distributed development challenges that I think it would be well suited to.

Brutal satire :-)

One thing that probably helped in this particular application is the way Erlang does threading. I believe it has its own user-level threading stuff. This makes the memory footprint and OS overhead significantly smaller than most applications (I think he made a remark about using 400 bytes per thread). I don't know what type of threads CL was using.

This is much like the poll/select versus threading model. For example, for years we were complaining that Java was unsuitable for large-scale servers because you had to do everything as heavyweight threads.

I have been using Erlang for about 4 years now but have never used threading in it... haha. Generally Erlang has a fairly hefty memory footprint and performance is slow compared to C or C++ but it's a nice language when those things don't matter. You can see in his example how the 27000 threads are using 600 MB of memory (!). That's a lot of memory for something relatively small scale.

This discussion on comp.lang.lisp is the source of the comment on Lemondor.