121–129 of 129 posts
I'm currently in the process of removing actix from one of my projects and replacing it with asyc/await and some channels. Actix comes with a ton of dependencies and doesn't buy you a whole lot anymore.
Earlier quoted context omitted.
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 practi…
Aren't they connected by the idea of active objects? https://en.wikipedia.org/wiki/Active_object
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.
Earlier quoted context omitted.
> I wouldn't call Actix the most mature Surely? I try several other for replace my .NET core project, and Actix is the only one that barely get there. Which other handle without much fuzz: - Auth (big!) - Routing with state and db pooling - Forms - Templates - Encode/Decode all stuff (query string, headers, etc) - Allow to inject middle-wares - Have (at least) the bare minimum of functionality like gzip encoding - An…
Actix has a lot of features, but to me that's not the same as maturity. I don't want one "batteries-included" framework, I want components (preferably mature and relatively boring) with well-defined interfaces that I can use together to build my backend.
Django, ROR pull a lot of people into.
I'm currently in the process of removing actix from one of my projects and replacing it with asyc/await and some channels. Actix comes with a ton of dependencies and doesn't buy you a whole lot anymore.
Yes. I would imagine Actix being out of favour now. Funny to see it being a rust project shared on hn
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 changed, and some additional restrictions like all messages being async and objects only being able to process one message at a time. Why is it necessary to create a whole new paradigm just to enforce such a style?
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 practi…
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 changed, and some additional restrictions like all messages being async and objects only being able to process one message at a time. Why is it necessary to create a whole new paradigm just to enforce such a style?
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.
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 changed, and some additional restrictions like all messages being async and objects only being able to process one message at a time. Why is it necessary to create a whole new paradigm just to enforce such a style?
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…
Earlier quoted context omitted.
Actually I think building oop on top of actor model makes the mental model far easier. Instead of worrying if the knight object uses the sword object to hurt the monster obect then which object .deals_damage? Or should the object take_damage? The actor framework, being all message passing, makes these choices clear. True, originally oop was message passing, but no mainstream modern oop languages except Ruby sorta are…
> no mainstream modern oop languages except Ruby sorta are message passing frameworks. Will changing the name fix that problem? I think any language or framework that gains widespread adoption will have to compromise its principles in some ways for the sake of pragmatism.
Earlier quoted context omitted.
> no mainstream modern oop languages except Ruby sorta are message passing frameworks. Will changing the name fix that problem? I think any language or framework that gains widespread adoption will have to compromise its principles in some ways for the sake of pragmatism.
Yes? There are modern FP languages (mostly in the BEAM family) that are excellent message passing frameworks in the Alan Kay OOP sense.
What I'm asking is, how will the actor model stop people from taking those pure ideas and turning them into another Java? Isn't it just a matter of time? If that's the case, then it hasn't really "fixed" anything about OO.