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

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.

Cheers
Marc

Ursprüngliche Nachricht

···

Von: swift-evolution@swift.org
Gesendet: 2. Oktober 2017 11:59 vorm.
An: swift-evolution@swift.org
Antworten: gerard_iglesias@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

···

2017-10-03 15:45 GMT+03:00 Marc Schlichte via swift-evolution < swift-evolution@swift.org>:

Cheers
Marc

  Ursprüngliche Nachricht
Von: swift-evolution@swift.org
Gesendet: 2. Oktober 2017 11:59 vorm.
An: swift-evolution@swift.org
Antworten: gerard_iglesias@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@swift.org> a écrit :

2017-10-03 15:45 GMT+03:00 Marc Schlichte via swift-evolution <swift-evolution@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@swift.org
Gesendet: 2. Oktober 2017 11:59 vorm.
An: swift-evolution@swift.org
Antworten: gerard_iglesias@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution