[erlang-questions] How to think and reason when designing process- and message-centric systems?

zxq9 <>
Fri Dec 16 02:58:52 CET 2016

Off-list reply due to the incomplete nature of the reference below.

On 2016年12月15日 木曜日 12:04:45 IRLeif wrote:
> Dear Erlang community,
> This is my first email to the mailing list. I apologize in advance if this
> is odd or off-topic.
> Coming from an object-oriented and data-centric background, I have
> cognitive difficulties when it comes to conceptualizing, thinking about and
> designing systems consisting of modules, processes and key-value data
> stores.
> My brain reverts to thinking about classes, objects, inheritance trees,
> encapsulation and SQL-style relational data models. I'm afraid this could
> lead to unidiomatic Erlang system architectures and implementations, which
> would be undesirable.

I have been working on a book for intermediate Erlang that starts out with
a conceptual architecture design section before getting into code. This section
is already written and may provide some "how to think about X" type things in


Beware of the code in the v0.1 section. It is deliberately written in an almost
anti-OTP style. I simply have not had the time to cover how to factor out the
common bits there, then expose how those common bits are already in OTP, and so
on. My work on this has been (mostly) stalled for about a year. :-/


If you want an example of a small-enough-to-digest but OTP-based project, there
is a UUID generator that can require a process be started to track the current
clock value in the case of very high-volume UUIDv1 generation. It is documented
and written in a style that was developed on the list in collaboration with all
the graybeards I could find:


The intent of the UUID project was to present a small example exactly for cases
such as this.

If you have time please check them out. Hopefully they can, in conjunction with
other resources such as "Learn You Some Erlang", get you up to speed without
too many hurdles. If you find them useful, feel free to pass them along.

I wrote a post on SO a while back about the difference between Java threads and
Erlang processes. The underlying point is that the differences between Java and
Erlang go way beyond (and are entirely orthogonal to) the difference between
OOP and FP. It would be entirely possible, for example, to implement a version
of Java on top of the Erlang VM -- but we would require adding a few primitives
to the language (some for concurrency, some for type completeness).


Have fun!

Remember the cardinal rule:
If you're not confused then you're not learning anything!


More information about the erlang-questions mailing list