[swift-evolution] Swift and actors

[Benjamin Garrigues]

I have the feeling concurrency and asynchrony related features are going to have vastly different requirements and typical use case on a mobile app and on a server.

If you take something like reactive programming , they're quite suited to the http request / response lifecycle where your state largely reside on remote servers ( db / cache etc) and every request starts from a blank sheet. So having a declarative approach of pseudo pure functions to create a data processing pipe works well. On a mobile app, you're basically spending all your user session mutating one big state, so the declarative approach may not work well to describe all the possible interactions.

Same goes for actors and blocking calls : if you're dealing with a few coarsed grained actors that handle a large state and communicate over an unreliable medium ( such as a network) , you're going to have a very different need than if all your actors run on the same cpu and each handle a very small part of your logic and data. In the second case you're using actors for thread safety and not really to manage failure or lag in actor to actor communications.



> Le 3 oct. 2017 à 15:54, Roope Kangas via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> 
> 
> 2017-10-03 15:45 GMT+03:00 Marc Schlichte via swift-evolution <swift-evolution at swift.org>:
>> The Actor paradigm is widely used in the telecommunications industry. You might want to have a look at SDL (https://en.m.wikipedia.org/wiki/Specification_and_Description_Language) with its processes similar to Actors.
>> 
>> Btw Erlang with its early actor support started in the telecommunications industry too.
>> 
>> 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. 
>>  
> 
> Might be a bit of an sidetrack but... 
> 
> 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.
> 
> That makes it a bit easier to understand where things can change than for example some other systems I have worked with.
> 
> 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 
> keeping around so called Futures and doing bookkeeping. And have had even less use for blocking calls to other actors (wait for response).
> 
> My main use case has been game servers where I have clear actor like things: a clan, player, or an tcp connection.
> 
> 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.
> 
> Roope
>  
>> 
>> Cheers
>> Marc
>> 
>>   Ursprüngliche Nachricht  
>> Von: swift-evolution at swift.org
>> Gesendet: 2. Oktober 2017 11:59 vorm.
>> An: swift-evolution at swift.org
>> Antworten: gerard_iglesias at me.com
>> Betreff: [swift-evolution] Swift and actors
>> 
>> Hi everybody,
>> 
>> Sadly I don’t have the time to participate on all the so interesting discussion about concurrency and actor stuff.
>> 
>> But I have a question.
>> 
>> 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.
>> 
>> 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.
>> 
>> Then I wonder if we/you have good use case where Actor paradigm can show real advantages ?
>> 
>> Something obvious to me that the dev tools would need to be very advanced for debugging in case of actor model use.
>> 
>> Cheers
>> 
>> Gerard
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171004/dbab4e31/attachment.html>