There are several concurrency models implemented on top of the JVM, for example, but their use is limited, partly because the vast majority of Java libraries assume the shared-object concurrency model provided by the core language.

Similarly, I’ve witnessed C++ projects get into trouble because they changed the concurrency model and never got around to rewriting their old code, and ended up having to develop incompatible implementations of the same features for both models.

thanks for providing the checklist as it helps to establish the bar for other languages.

I would say that not all of the checklist are *fundamental* to have in the core language *if* the language has good extension facility.

The fundamental ones, i.e. difficult if not impossible to have at module level, are the microthreads and asynchronous message passing – the rest can be built as extensions.

I have just built the selective reception capability as a module for PLT Scheme on top of its microthreads – http://weblambda.blogspot.com/2009/09/erlang-style-programming-in-plt.html – distributed message and process monitoring can also be added in due time (and necessary effort of course).

It is true for other languages that cannot blur the line between the language and the extensions, the language provider would have to work harder to provide most if not all of the checklist.

One counter-argument might be that distribution wasn’t added to Erlang until 1993 – after the publication of the first Erlang book! (:

However, the idea of Distributed Erlang was there from the start, and the semantics of process spawning and message passing were created with distribution in mind.

Also, as you point out, process creation and teardown is the interesting bit in a dynamic system. As Erlang processes have separate heaps, terminating a process is basically a free() operation + possibly sending notifications to linked processes.

In practice, this tends to mean that you can indeed spawn and kill a process in only a few microseconds on a modern machine. However, I haven’t really attempted to obtain a precise number, and this is not entirely trivial either, since both process creation and process termination are asynchronous operations.

With ‘update’ I assume you mean code update? Processes tend to either pick up the newest code automatically the next time they enter that module, or can be written to switch to the new code only at a given signal. If processes need to be synchronized during code update (and this is not at all uncommon), OTP provides a set of conventions and control messages to achieve this using normal Erlang message passing.

With some forethought, one can also use pattern matching at message reception to handle both new and old message formats and act accordingly. This can be particularly useful when processes reside on different nodes, making consistency more expensive. It does clutter the code somewhat, of course.