8 ms·

What is the difference between the actor model and object oriented programming? It seems to me like they are basically the same paradigm but with all the names

• vbezhenar 7y ago
  You can run every actor in a separate thread or even in a separate machine, making the whole system highly scalable. Whether you'll consider that a new paradigm or not, is question of definitions.
  • shawnz 7y ago
    Isn't that basically the same as remote method invocation in OO systems?
    • nicoburns 7y ago
      It depends what you mean by OO. The Actor system is basically Smalltalk-style OO. Which is very different to Java-style OO, or JavaScript-style OO. Most people who talk about OO, are talking about the Java style.
    • bsaul 7y ago
      The way i see it : Object is the association of some functions with a state Actor is the association of object with an execution thread. So, actor = bounded (functions , state , thread) (thread in the sense of execution thread, not necesseraly an OS thread). With this definition, actors can't "share" a thread, and so need to communicate through asynchronous message passing / function invocation.
    • imtringued 7y ago
      Although I'm not sure what you really mean by "remote method invocation", the idea of remote method invocation in OO systems should be impossible or incredibly difficult considering the semantics of a method call. Method calls are synchronous and they are not allowed to fail under any circumstance. But in the context of distributed systems you have to choose between at most once or at least once delivery which are semantically incompatible with OOP style method calls. Your methods will have to be written with the expectation that they are called multiple times or maybe not at all and most OOP code doesn't satisfy these expectations because the OOP model doesn't require it. If you extend the OOP model with message semantics of the actor model then what you get is not just OOP+messaging. It's the actor model. Also you may have misunderstood something very fundamental. The benefit of paradigms isn't to be completely different. It's that everyone that shares a paradigm follows the same design philosophy. Imagine a mixed code base consisting of traditional OOP (with locks), actor model, async/await, promises. It would be very difficult to understand and sometimes it isn't obvious which of these is used. Some functions are asynchronous or they may fail but you may not know that because every single line could do a different thing. They may even be incompatible with each other. If you follow a single paradigm instead of many different ones you can avoid a lot of confusion and wasted work.
      • brucenanner 7y ago
        Not nearly impossible. Was put in the jdk like 20 years ago. RMI: https://en.m.wikipedia.org/wiki/Java_remote_method_invocation https://en.m.wikipedia.org/wiki/Java_remote_method_invocatio...
        • shawnz 7y ago
          Another example is Distributed Smalltalk from 1987
        • macintux 7y ago
          It’s impossible to make RMI behave exactly like local method invocation. It introduces many error cases and performance challenges you don’t normally have to consider.
        • jerf 7y ago
          There have been dozens or hundreds of things called "remote method" or "remote procedure" or "remote function" invocation. However, not a single one of them has overcome the fundamental problem that you can not have something that is semantically identical to the function call presented by programming languages, because programming language functions simply do not have the concept that you are accessing it over a network, and they take heavy and critical advantage of the resulting simplifications. Someone more clever than wise may stand up and point out that technically even a local function call is unreliable in many of the same ways that a network call is. However, even if many of the same problems can theoretically arise, the distribution of the problems are fundamentally different, which is why you do not guard every single function call in your program for all the network-type errors, and it generally works, whereas if you program that way in a networked environment, it generally does not work. Personally I've come to prefer messages very strongly to "RPC" as the foundation of a system. Messages can trivially implement an RPC-like system, but RPCs can not implement a message-like system. Even if you implement an RPC called "SendMessage", you're still adding synchronization on the RPC system sending over the call and waiting for the response. Among other things, but that's the big one.
          • 7y ago
    • vbezhenar 7y ago
      Remote method invocation is inherently a bad idea, because real world remote systems have significant latencies. Ordinary function call is few processor cycles. Network function call is few billions of processor cycles. While abstraction is a good thing in general, that kind of abstraction is not a good thing. That's the reason why remote calls today are using explicit syntax, API and so on. But with actors it's expected that sending a message to actor is something that takes some time. So you have a clear separation between ordinary function calls and actor messages. Of course it's still a lot of difference between sending message to a thread or sending message to another machine. So take that with a grain of salt. But at least you can utilize multicore CPUs.
    • whatshisface 7y ago
      The big difference is that you can pass an object to a method of another object, but you can't send an actor through a message channel. That jives with threads because a thread can't climb in to the stack and get passed through another thread.
      • M2Ys4U 7y ago
        You should be able send a handle to an object through a message channel, though.
• Isn0gud 7y ago
  In the Actor model, all function calls are async and have no return value, between the Actors. Each Actor is single threaded (OOP) program. It provides a nice approach to deal with parallel programming. Object oriented programming is a language feature while the Actor paradigm can be build on top of OOP to ease the mental burden of parallel programming.
  • danieldk 7y ago
    In the Actor model, all function calls are async and have no return value, between the Actors. Each Actor is single threaded (OOP) program. It provides a nice approach to deal with parallel programming. I guess you mean 'concurrent programming', right? I haven't seen actors used a lot for parallelism.
    • hopia 7y ago
      Yeah actor model is a good fit for distributed concurrency. For single machine concurrency, let alone parallel computing it may not be the ideal choice.
    • alecmg 7y ago
      Actor model is good for parallelisation. Each Actor and its message queue can be processed separately from everything else. There should be no side effects except new messages sent or new actors spawned. So a pool of worker actors can absolutely work in parallel. In fact now I'm curious if Actix supports that
      • macintux 7y ago
        Typically parallelism is particularly interesting for performance, and the (usually?) shared-nothing architecture of the actor model is not conducive to high performance computing.
        • deleted 7y ago
          [deleted]
        • 7y ago
• edejong 7y ago
  Your question is interesting from the perspective that the actor model could be seen as the precursor to modern object oriented programming. Both the actor model as defined by Carl Hewitt and the early object computational models as they are defined by Alan Kay (Smalltalk) originated during the same period and are based on similar philosophies of computation. However, on the object oriented model track, due to practical reasons, its definition descended into a single-thread dispatch system with full message delivery guarantees. Locality was dropped (due to singletons) and the distributed model was not maintained. Method dispatch systems were later added, but could be considered a kludge. This also explains the mismatch between remote systems calls (SOAP, REST, etc.) and the internal language. Ideally, these would be the same. With our modern systems design constraints, especially given distributed systems, we need to revisit those early decisions. The Actor model is a good blueprint for our designs. It is fundamentally decentralized, locality is enforced and at-most-once message delivery is assumed. These allow us to design and implement distributed algorithms which would be hard to implement using traditional OOP methods.
  • dkn 7y ago
    I think this is a great summary, and also highlights much of what Joe Armstrong talked about when comparing Erlang to other OO languages, and his earlier decisions to design Erlang to work in the same way whether in a single-node or multi-node environment.
  • sakian 7y ago
    Aren't they connected by the idea of active objects? https://en.wikipedia.org/wiki/Active_object https://en.wikipedia.org/wiki/Active_object
    • RossBencina 7y ago
      Based on the description in your Wikipedia link there is a relationship for sure -- but I don't see a strong connection. Here's how I see it: An Active Object is essentially an OO encapsulation of a worker thread. It provides clients with a synchronous call interface where all results are resolved asynchronously (e.g. using futures for results). Internally, the Active Object converts client requests into asynchronous operations, enqueues the operations, and executes them on a private worker thread using object-specific dispatcher logic. In an OO system, not all objects are required to be Active Objects. So there may be a mixture of synchronous and asynchronous execution. In contrast, in an Actor system all communication is via asynchronous messages and there is no inherent requirement for multiple concurrent threads of execution. Active Objects use a mechanism such as futures to return results. On the other hand, if there is a request-reply message exchange in an Actor system, both the request and the reply will be separate messages. The client would receive the result of a computation by receiving a message. The relationship I see between Actors and Active Objects is that both require some kind of queue for dispatching operations (since Actor behaviors are never re-entrant). Active Objects convert synchronous calls into asynchronous operation requests, whereas Actors use asynchronous messages for _all_ inter-entity communication. I agree with the GP that event loop programming is the closer OO analogue of Actors.
• zelly 7y ago
  OOP is about passing messages through memory. Actors are about passing messages through time.
• jlouis 7y ago
  I think the key point is that most actor models, at least the ones I know, are truly concurrent with preemption, whereas most models based on OO are sequential. There is only one thread of execution in the OO program, whereas there is no notion of this in an actor system. All processes execute at the same time, so to speak. There are also some points with the messaging being truly asynchronous, so you can't rely on the order in which messages arrive, usually subject to certain constraints. Erlang, for instance, require that between any two pairs of processes, order is preserved in the messages. Also, creating a new actor creates a new thread of execution inside that actor. This is not the same as creating a new object.
• acjohnson55 7y ago
  The other replies have covered this pretty well, but the two models are quite similar. The big difference is the formal constraints of the actor model, which allow people to build robust distributed systems. This is because the lack of certainty of communication and architecture is assumed as a first principle. This makes a big difference, in practice, for what programs actually look like.
• dragonsh 7y ago
  OOP and Actor model followed parallel paths of evolution: the Actor Model was created by Carl Hewitt based on the message passing semantics of Smalltalk. Alan Kay, in turn had based the message passing semantics of Smalltalk on the goal-driven evaluation of PLANNER, which was designed by Carl Hewitt. PLANNER was the precursor to Prolog. Erlang a language based on actor model where processes are actor was originally not intended to be a language, rather it started out as a library for fault-tolerant distributed programming in Prolog, and later evolved into a dialect of Prolog, before it became its own language, still to this day heavily influenced by Prolog. So, the similarities between Objects in OO, and Actors in the Actor Model are far from coincidental.
• zackmorris 7y ago
  To me, the biggest difference is that the actor model has no shared memory between classes like with object-oriented programming. I'd actually like to see OO programming where classes are completely isolated, but to my knowledge, that doesn't really exist. Go, Elixir and Erlang come close. UNIX shell with isolated processes communicating over streams -> Actor model Pretty much every C-style language with all of their caveats -> Object-oriented model
  • buckminster 7y ago
    > OO programming where classes are completely isolated That sounds like COM, especially the Automation subset.
  • jerf 7y ago
    Elixir/Erlang/BEAM, as far as I know, semantically don't just come close, they arrive. I say "semantically" because there are some optimizations for things like large binaries so the system isn't literally copying a lot of them around unnecessarily, but semantically, BEAM processes are isolated from each other entirely. Go doesn't come close; technically it's just another shared-state programming language. Culturally, it tends to use more sane concurrency features, and the channels are nice and all, but technically there is no isolation between goroutines. With discipline, you can program Go with an actor mentality and it's fairly effective. I do it all the time, leaning on my years of experience in Erlang and some Haskell, which teaches you how to build systems that work that way. But you do need non-trivial discipline as the language provides rather less help with than I'd like.
  • ahasani 7y ago
    Sharing state is what actor model tries to eliminate, it has a very strong locality concept. Singleton in OOP (which you have to implement atomic and thread safety often by yourself) can be easily implemented as an actor. Erlang has gen_server for this exact scenario. About isolation, you can actually impose class isolation in OO languages by declaring all variables as private. Public variable can never happen in actor model
• zamalek 7y ago
  The way I like to think of it is: actors combine objects (allocated objects, specifically) and threads. You wouldn't really allocate a thread per object, but that's an implementation detail. Message passing etc. all follow from the restrictions that arise due to objects being threads. The restrictions you talk about are the key advantage of the actor model. OOP is extremely powerful, and nobody seemingly knows how to use that power responsibly. Actors introduce just enough rails to drive you into the pit of success. Just like Rust imposes restrictions to improve the reliability and security of software, Actors impose restrictions that improve the human comprehension and reasoning of software architecture.
• eweise 7y ago
  I haven't looked at this framework but from the one I am familiar with, once you make the calls async, the objects can live anywhere, locally or remote. Also, you may have to assume that messages don't get processed and thus need to handle that case. The upside is that distributing your app becomes a configuration issue instead of a coding one. This is nice because with microservices, the seams need to be decided upfront and its hard to refactor if you get it wrong.