<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-10-03 15:45 GMT+03:00 Marc Schlichte via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The Actor paradigm is widely used in the telecommunications industry. You might want to have a look at SDL (<a href="https://en.m.wikipedia.org/wiki/Specification_and_Description_Language" rel="noreferrer" target="_blank">https://en.m.wikipedia.org/<wbr>wiki/Specification_and_<wbr>Description_Language</a>) with its processes similar to Actors.<br>
<br>
Btw Erlang with its early actor support started in the telecommunications industry too.<br>
<br>
An advantage of the proposed actor design for Swift (and also present in Microsoft Orleans) over Akka and others is the use of value returning async actor methods which allow for a more procedural programming style - as opposed to a pure message passing style which is indeed harder to follow / debug. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> </blockquote><div><br></div><div>Might be a bit of an sidetrack but... </div><div><br></div><div>Yes, well in Erlang systems you have immutable state. When you receive a message you return a new state from the function handling it, or just crash and let the system log your state and the message that caused the this.</div><div><br></div><div>That makes it a bit easier to understand where things can change than for example some other systems I have worked with.</div><div><br></div><div>When I have written these Actor based programs, I have preferred to keep the messaging asynchronous. There I personally do not see a value of <br></div><div>keeping around so called Futures and doing bookkeeping. And have had even less use for blocking calls to other actors (wait for response).</div><div><br></div><div>My main use case has been game servers where I have clear actor like things: a clan, player, or an tcp connection.</div><div><br></div><div><div>But yes, you still need tools to sometimes debug the system. While developing a unit testing framework with ability to start actors and easily pass message to them can go a long way.</div></div><div><br></div><div>Roope</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Cheers<br>
Marc<br>
<br>
Ursprüngliche Nachricht <br>
Von: <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
Gesendet: 2. Oktober 2017 11:59 vorm.<br>
An: <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
Antworten: <a href="mailto:gerard_iglesias@me.com">gerard_iglesias@me.com</a><br>
Betreff: [swift-evolution] Swift and actors<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
Hi everybody,<br>
<br>
Sadly I don’t have the time to participate on all the so interesting discussion about concurrency and actor stuff.<br>
<br>
But I have a question.<br>
<br>
I am working for 6 months in the Scala/Akka world, on a project (server stuff in a docker kubernates world) and after six months of work, and talk with Scala experts we are abandoning the actor paradigm. It is true that quickly the code is hard to follow, maybe our fault but I have to say that it seems me that the nature itself of the actor system bring some opaque way to follow what happen in the system. Even for a small set of actors.<br>
<br>
It has been very fun to try an architecture based on Actors, but at the end, this is not easy to see what use case they are good for.<br>
<br>
Then I wonder if we/you have good use case where Actor paradigm can show real advantages ?<br>
<br>
Something obvious to me that the dev tools would need to be very advanced for debugging in case of actor model use.<br>
<br>
Cheers<br>
<br>
Gerard<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br></div></div>