<div dir="ltr"><div><div>I think it is very lucky that we weren't interested in, or worried about, the theoretical aspects, or that we had heard about the actor model. If we had we would probably still be discussing whether we were doing the actor model and which parts of it, or where we differed and how important that was? Or should we differ and maybe we should drop the differences to we would comply, etc ... :-)<br>

<br></div>We were trying to solve *THE* problem and this was the best solution we could come with. It was purely pragmatic. We definitely took ideas from other inputs but not from the Actor model.<br><br></div>Robert<br>
<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On 24 June 2014 23:05, Miles Fidelman <span dir="ltr"><<a href="mailto:mfidelman@meetinghouse.net" target="_blank">mfidelman@meetinghouse.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">zxq9 wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
I think the more important aspect here being that its very hard to be happy<br>
with concurrency in a world where you have to handle every combination of<br>
message*state, and that means fault tolerance is a neccessary component of any<br>
environment where one can happily build large concurrent systems. In<br>
particular, any large system is non-trivial, and concurrency itself is non-<br>
trivial. Without fault-tolerance you wind up with an explosively complex fault<br>
situation to handle.<br>
<br>
<br></div><div class="">
Come to think of it, I don't think it would be very easy to apply Erlang's<br>
concept of fault-tolerance without pattern matching as a central feature in<br>
many areas of the language. I could be wrong, I'm just trying to imagine an<br>
alternative without pattern matching -- and I don't see any alternative than<br>
to emulate it with exclusive guards or something (which still equates to<br>
pattern-matching, just less easy to read), which in the extreme case is almost<br>
as bad as the common practice in some languages of actually enumerating every<br>
negative case -- which usually vastly outnumber the positive cases -- and<br>
providing an exception handler for each.<br>
</div></blockquote>
<snip><br>
<br>
Well, falling further down the rabbit hole ....<br>
<br>
I kind of agree with you that massive concurrency and fault-tolerance go hand-in-hand.<br>
<br>
On the other hand, I kind of see pattern matching as more associated with message-oriented communication:  Somehow I don't see doing a lot of message selection and processing without pattern matching at the front end.<br>


<br>
Cheers,<br>
<br>
Miles<div class="im HOEnZb"><br>
<br>
-- <br>
In theory, there is no difference between theory and practice.<br>
In practice, there is.   .... Yogi Berra<br>
<br></div><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>