Will there be any actor model abstraction in Verona?

[shafqatevo]

Hi,

Will there be any actor model abstraction in Verona? If not, why not? Seeing Verona taking inspiration from Pony, the actor model abstraction seems a good option for concurrency and allowing relatively higher level programming style.

Thanks!

[mjp41]

We have taken a different approach in Verona. The concurrency model we are building in Verona is strictly more powerful than the Actor model. However, it does take a different shape. There is an explanation of it here:

https://github.com/microsoft/verona/blob/master/docs/explore.md#concurrent-ownership

The rest of my comment assumes you have read the link.

A program where every when has a single cown, has the same concurrency as Actor model programming. However, the code is structured differently. Rather than associating the code directly with the cown, we have behaviours, when, which specify what to do. The language can still provide encapsulation, but encapsulation and concurrency are not conflated in the same way.

The motivating example for us it transaction processing type things. which are hard to express in Actors, and typically require the programmer to build a level of locking on top of the actor messages. Consider building a database in an Actor model system. What is the natural level of concurrency, whole database, table or record? Let say you want concurrency at the table level. Then in the Actor model system you might consider each table is an Actor. But then how do you modify two tables in a transaction. Well, you would need to message each table, and then get them to coordinate over whether the transaction succeeded. This effectively builds locking on top of the Actor model. In Verona with cowns we can write a when over the required cowns and it will execute on those tables in isolation.

I hope this explains our current choices, but please do follow up if you have more questions.

This is a research project and time will tell if the extra flexibility that cowns provide over actors is the right way to go. We have a more stuff in preparation on this topic.

[plietar]

In addition to the difference in the underlying concurrency model @mjp41 talked about, Pony and Verona differ in how that concurrency is exposed to the programmer.

In Pony, concurrency is chosen at the definition sites. An entity is declared as an actor instead of a class, and behaviours are declared using the be keyword instead of fun. In Verona however, you can only define classes and methods. It is up to the user of the class to decide whether to treat the class as an "actor" by wrapping it in a cown, and then use when blocks to create behaviours. This allows more flexibility and composition.

Say the BankAccount class only has balance(): U64 and a withdraw(amount: U64) methods, the user of the class can write a behaviour that atomically clears the account.

// b: cown[BankAccount]
when (b) {
    var balance = b.balance();
    b.withdraw(balance);
}

In Pony however, the only way to achieve this would have been to define a clear() behaviour in the BankAccount class itself. If the author of the class didn't include this method, then there is no way to implement this.

[shafqatevo]

Thanks @mjp41 and @plietar for the helpful explanations. I have read and watched as much as I could access on Verona stuff on the web.

I do understand this is a powerful and composable concurrency primitive and higher level actor model abstractions can be created out of these mechanisms, perhaps as a library. And Verona is after all a research project with experimentation goals beyond actors.

However, I am yet to see a modern lang that is implementing actor model proper (Hewitt, Agha). Pony's actor model is also quite different as you can see in this thread where I explained some of the differences and as a result an important bonus of getting an FSM out of an actor is lost, among other lost features:
https://ponylang.zulipchat.com/#narrow/stream/189985-beginner-help/topic/Actor.20behaviors.20as.20a.20state.20machine

Even Swift, a lang that is recently embracing actor model, is implementing it quite differently. Only Akka seems to be as close as it gets to the original model.

I am curious - with actor model itself, can't both the cown and region features be implemented? The cown-when is basically the Serializer concept of actor model and regions could be the encapsulated object graph within an actor. For transactions on shared resources, a combination of Serializers and Synchronizers (the other actor model concept) can be used. Serializers are as much locking as cown-when serialization is, which is minimal async locking, and serializers can be a built-in feature in an actor lang.

I am sure, like me, many people are eagerly waiting for a straight-forward implementation of actor model in a lang that will be compliant with the original model so that the various theoretically proven/analyzed benefits of actor model can be leveraged, including the ongoing work on model checking and verification for deadlock safety, etc. And also so that an industry standard on actor model emerges for people to discuss, expect and design on the same concept in a consistent manner.