8 ms·

> Orbit is a framework to write distributed systems using virtual actors on the JVM. A virtual actor is an object that interacts with the world using asynchrono

> Orbit is a framework to write distributed systems using virtual actors on the JVM. A virtual actor is an object that interacts with the world using asynchronous messages. Could anybody elaborate on this? How does an actor differ from an object that uses promises to talk to a server?

mjburgess 4y ago
Yip, that's basically just an actor. When people talk about actor-based languages or frameworks however, theyre suggesting syntax primitives which help express this more naturally. The simple pitch is: OO where objects could be on any machine.
pdpi 4y ago
Objects, actors, and (micro-)services are basically the exact same concept at different scales.
- spinningslate 4y ago
  To some approximation. The Actor Model formalism [0] requires certain properties, notably: 1. Communication solely by asynchronous message passing 2. A mailbox per actor that means the reception of messages and the processing of them is decoupled (i.e. an actor can receive new messages even when processing a previously-received message). The OO model in general supports that paradigm. Pretty much all mainstream OO languages are synchronous by default though. Call a method and the caller is suspended until the method returns. Multiple clients can call methods on the same object concurrently, but doing that safely requires some form of locking/protection to be implemented in the target object. Stated alternatively: threads in mainstream OO languages run "across" objects, whereas each actor has its own thread in the Actor model. There are certainly similarities - in the sense that both actors and objects encapsulate state, with reading/writing occurring through well-defined interfaces (messages and methods respectively). But the threading model is quite different - it's not just a matter of scale. [0] https://en.wikipedia.org/wiki/Actor_model https://en.wikipedia.org/wiki/Actor_model EDIT: corrected grammar & formatting.
- usrusr 4y ago
  Thanks for making me feel old by not including agents in the list. Those seem even more similar to actors. At least until someone mentions BDI, then it's suddenly an entirely different universe.
asadawadia 4y ago
actor model has nothing to do with promises
beardedetim 4y ago
Usually the difference is the "mailbox" an actor has, making the difference more about the level you're calling an actor more than the differences in any code you might write.
diroussel 4y ago
It’s not the same as async objects. There are differences between different score systems. But have a look at Elang and Akka for example. But I’m actor systems the actors maybe more stateful that you typical object and be location transparent. Communication between actors does require knowledge of if another actor is in process or remote. Also the actor supervising model is a completely different way of recovering from errors than in OO systems.
whoisthemachine 4y ago
A promise is a specific class of an actor - https://en.wikipedia.org/wiki/Futures_and_promises#Semantics_of_futures_in_the_actor_model https://en.wikipedia.org/wiki/Futures_and_promises#Semantics...
xeromal 4y ago
This is based on a popular and fundamental computer science paradigm. If you're not familiar with it, it's a good read. https://en.wikipedia.org/wiki/Actor_model https://en.wikipedia.org/wiki/Actor_model
yashap 4y ago
Actors are useful for keeping code clean/understandable/correct when dealing with heavy concurrency AND lots of mutable state. Actors are like objects, but the only way to interact with them is sending them a message - you can’t directly access their properties, call their methods, etc. Messages are bits of immutable data sent between actors asynchronously, but those messages go into the actor’s mailbox, and then the actor processes them synchronously, one at a time. You can get parallelism by adding more actors of the same type (10 actors of the same type lets you process up to 10 messages concurrently). Because actors are totally synchronous INTERNALLY, and nobody can directly access their internal state, it’s fine for them to have mutable internal state, with no locking/synchronization needed, and much easier to reason about than mutable state normally is in highly concurrent applications. With that being said, the actor model has a lot of inherent complexity. If you don’t need it, don’t use it. But if you really do need lots of concurrency and lots of mutable state, it’s often a great choice. They’re also good for distributed systems. Actors only communicate by sending messages to other actors, but it doesn’t really matter if that message is sent in memory to an actor in the same process, or over the network to an actor on a different machine. So you can take a single actor system and split it across many machines pretty easily. Generally the actor framework you’re using will handle delivering messages over the network, ensuring there’s the right number of actors running across all nodes combined, etc.
- dragonwriter 4y ago
  > Actors are like objects, but the only way to interact with them is sending a message - you can’t access their properties, call their methods, etc. While the implementation in many popular, e.g. C++ and family descended from it, languages muddies the waters, basically methods in OO are a convenient way to define handlers for messages sent to objects, and in pure OO you also can't interact with objects except by sending messages to them. The difference between the basic OO model and the actor model is that OO message sends are synchronous request/response and actor model message sends are asynchronous fire-and-forget.
  - yashap 4y ago
    Agreed, although it’s not always fire-and-forget (i.e. send a message and don’t wait for a response). Actors generally do support request/response style messaging, but it’s always async - it’s really only synchronous request/response communication that’s not allowed.
ctvo 4y ago
This is a very broad question. I would start with understanding the concept of actors. You'll end up reading about Erlang, Akka, etc. Then what's a virtual actor and how does it differ? You'll eventually end up at the Orleans paper from MSFT research: https://www.microsoft.com/en-us/research/publication/orleans-distributed-virtual-actors-for-programmability-and-scalability/ https://www.microsoft.com/en-us/research/publication/orleans... It really has nothing to do with promises (as used colloquially) and is a way to design large distributed systems using message passing and localized state that's persisted.
dordoka 4y ago
It implements the actor model paradigm. Check this video https://www.youtube.com/watch?v=7erJ1DV_Tlo https://www.youtube.com/watch?v=7erJ1DV_Tlo
birdyrooster 4y ago
Highly suggested watch the creator of the actor model explain to some skeptics. https://youtu.be/7erJ1DV_Tlo https://youtu.be/7erJ1DV_Tlo

mjburgess 4y ago

Yip, that's basically just an actor. When people talk about actor-based languages or frameworks however, theyre suggesting syntax primitives which help express this more naturally. The simple pitch is: OO where objects could be on any machine.

pdpi 4y ago

Objects, actors, and (micro-)services are basically the exact same concept at different scales.

spinningslate 4y ago
To some approximation. The Actor Model formalism [0] requires certain properties, notably: 1. Communication solely by asynchronous message passing 2. A mailbox per actor that means the reception of messages and the processing of them is decoupled (i.e. an actor can receive new messages even when processing a previously-received message). The OO model in general supports that paradigm. Pretty much all mainstream OO languages are synchronous by default though. Call a method and the caller is suspended until the method returns. Multiple clients can call methods on the same object concurrently, but doing that safely requires some form of locking/protection to be implemented in the target object. Stated alternatively: threads in mainstream OO languages run "across" objects, whereas each actor has its own thread in the Actor model. There are certainly similarities - in the sense that both actors and objects encapsulate state, with reading/writing occurring through well-defined interfaces (messages and methods respectively). But the threading model is quite different - it's not just a matter of scale. [0] https://en.wikipedia.org/wiki/Actor_model https://en.wikipedia.org/wiki/Actor_model EDIT: corrected grammar & formatting.
usrusr 4y ago
Thanks for making me feel old by not including agents in the list. Those seem even more similar to actors. At least until someone mentions BDI, then it's suddenly an entirely different universe.

asadawadia 4y ago

actor model has nothing to do with promises

beardedetim 4y ago

Usually the difference is the "mailbox" an actor has, making the difference more about the level you're calling an actor more than the differences in any code you might write.

diroussel 4y ago

It’s not the same as async objects. There are differences between different score systems. But have a look at Elang and Akka for example. But I’m actor systems the actors maybe more stateful that you typical object and be location transparent. Communication between actors does require knowledge of if another actor is in process or remote. Also the actor supervising model is a completely different way of recovering from errors than in OO systems.

whoisthemachine 4y ago

A promise is a specific class of an actor - https://en.wikipedia.org/wiki/Futures_and_promises#Semantics_of_futures_in_the_actor_model https://en.wikipedia.org/wiki/Futures_and_promises#Semantics...

xeromal 4y ago

This is based on a popular and fundamental computer science paradigm. If you're not familiar with it, it's a good read. https://en.wikipedia.org/wiki/Actor_model https://en.wikipedia.org/wiki/Actor_model

yashap 4y ago

Actors are useful for keeping code clean/understandable/correct when dealing with heavy concurrency AND lots of mutable state. Actors are like objects, but the only way to interact with them is sending them a message - you can’t directly access their properties, call their methods, etc. Messages are bits of immutable data sent between actors asynchronously, but those messages go into the actor’s mailbox, and then the actor processes them synchronously, one at a time. You can get parallelism by adding more actors of the same type (10 actors of the same type lets you process up to 10 messages concurrently). Because actors are totally synchronous INTERNALLY, and nobody can directly access their internal state, it’s fine for them to have mutable internal state, with no locking/synchronization needed, and much easier to reason about than mutable state normally is in highly concurrent applications. With that being said, the actor model has a lot of inherent complexity. If you don’t need it, don’t use it. But if you really do need lots of concurrency and lots of mutable state, it’s often a great choice. They’re also good for distributed systems. Actors only communicate by sending messages to other actors, but it doesn’t really matter if that message is sent in memory to an actor in the same process, or over the network to an actor on a different machine. So you can take a single actor system and split it across many machines pretty easily. Generally the actor framework you’re using will handle delivering messages over the network, ensuring there’s the right number of actors running across all nodes combined, etc.

dragonwriter 4y ago
> Actors are like objects, but the only way to interact with them is sending a message - you can’t access their properties, call their methods, etc. While the implementation in many popular, e.g. C++ and family descended from it, languages muddies the waters, basically methods in OO are a convenient way to define handlers for messages sent to objects, and in pure OO you also can't interact with objects except by sending messages to them. The difference between the basic OO model and the actor model is that OO message sends are synchronous request/response and actor model message sends are asynchronous fire-and-forget.
- yashap 4y ago
  Agreed, although it’s not always fire-and-forget (i.e. send a message and don’t wait for a response). Actors generally do support request/response style messaging, but it’s always async - it’s really only synchronous request/response communication that’s not allowed.

ctvo 4y ago

This is a very broad question. I would start with understanding the concept of actors. You'll end up reading about Erlang, Akka, etc. Then what's a virtual actor and how does it differ? You'll eventually end up at the Orleans paper from MSFT research: https://www.microsoft.com/en-us/research/publication/orleans-distributed-virtual-actors-for-programmability-and-scalability/ https://www.microsoft.com/en-us/research/publication/orleans... It really has nothing to do with promises (as used colloquially) and is a way to design large distributed systems using message passing and localized state that's persisted.

dordoka 4y ago

It implements the actor model paradigm. Check this video https://www.youtube.com/watch?v=7erJ1DV_Tlo https://www.youtube.com/watch?v=7erJ1DV_Tlo

birdyrooster 4y ago

Highly suggested watch the creator of the actor model explain to some skeptics. https://youtu.be/7erJ1DV_Tlo https://youtu.be/7erJ1DV_Tlo