Bill Clementson has been posting about concurrency in programming languages and linked to me about my use of Erlang.
I've been using Erlang for a personal project for the last few months and I've found it very easy to use. The ability to spawn processes without the need to worry about any practical limits is quite interesting. I've found that I've started thinking about concurrent solutions to problems rather than strictly OO or functional solutions.
Some people ask 'why would anyone need thousands of threads'. My answer is 'why not'? If it makes the program easier to write, maintain and understand, why should a programming language or implementation create an arbitary restriction?
It is especially useful for network applications. I'm using the Yaws webserver written in Erlang with a library I wrote to do server side push of events from the webserver to web browser clients. This results in a large number of server connections and Erlang models this easily with one process per connection with a low overhead compared to native threads.
The common objection related to not being able to use SMP machines will be addressed with an upcoming Erlang release that uses native thread pools to distribute the process load.
I also continue to maintain and extend the concurrency library I wrote for Factor. Currently I'm adding binary serialisation (based on the Pickler Combinators paper). The intent of this is to allow serializing Factor continuations and thus provide migrating processes and distributed concurrency. I use this as a means to explore concurrency methods at a lower level which gives me a greater understanding of how to use it in systems like Erlang. And ultimately I'd like it to become a productive and usable system in its own right.