<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 15, 2016 at 10:51 PM, Onorio Catenacci <span dir="ltr"><<a href="mailto:Catenacci@ieee.org" target="_blank">Catenacci@ieee.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Your comments are certainly illuminating for someone like myself who doesn't know the various details of Erlang's messaging model as deeply as you do.</blockquote></div><br>Another quite interesting concurrency model is STM from Haskell. It also supports composition of atomic operations. That model, at a lower expression level can be found in the "reagents" idea[0], which is probably becoming the basic concurrency model of multi-core OCaml. It is an exiting time to be interested in concurrency for sure.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In some way, the Erlang model is the Ur-model of everything. It is the simplest model you can build over an unreliable network at the base. Everything else has to "factor through" the Erlang model, but may provide for a nicer system on top. In other ways it is not the Ur-model. I regard the fact you can't compose receive-expressions as a mistake for instance. It would require us to have receive patterns as first-class.</div><div class="gmail_extra"><br></div><div class="gmail_extra">[0] <a href="http://kcsrk.info/ocaml/multicore/2016/06/11/lock-free/">http://kcsrk.info/ocaml/multicore/2016/06/11/lock-free/</a><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">J.</div>
</div></div>