Link Details

This really doesn't do justice to Erlang at all. At best, it's a bunch of threads and a one-queue-per-thread model that's fairly trivial to do. It doesn't actually prevent races or synchronization; in fact, it would be easy for a synchronized object to participate in this causing deadlock.

An interested reader might like to read the Scala actors design model, which looks into detail at the way in which message-passing concurrency might work at several levels. One that is considered (and rejected) is that of one-thread-per-consumer, and is shown to be both overly heavyweight and far less performant than other approaches.

Erlang was written from the ground up with concurrency and fault tolerance in mind, so it can enforce thread safety at the language level. Retlang is just a library. It cannot change the nature of the implementation language. However, a well designed application written with Retlang will not have races, locking, or potential for deadlocks.

Retlang does not mandate one-thread-per-consumer. One thread can service any or all consumers.

Retlang does not "prevent" synchronization, but it removes the need. With the messaging model, the application developer should never need to lock anything. It is .NET after all so there is no way to "prevent" a developer from randomly locking objects, even though it is unnecessary.

The library also does not "prevent" races but neither does erlang. Parallel execution is the goal after all. With Erlang or Retlang, races can be easily avoided. It is a design consideration not an enforced constraint.

Retlang absolutely doesn't do justice to Erlang. It is impossible to compare a library to a complete programming language and culture. However, Retlang makes it possible to apply the ideas found in Erlang to the world of .NET.

As of version 0.2.2.0, Retlang supports a queue-per-thread model as well as a lightweight contexts that leverage a shared thread pool. Contexts are just plain objects, so they are cheap to create and destroy. The backing pool will be optimized for the number of cores and cpu's on the machine, so a Retlang based application will scale very similarly to an erlang application.