[Isn0gud]

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.

[dnautics]

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 message passing frameworks.

[shawnz]

> 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.

[dnautics]

Yes? There are modern FP languages (mostly in the BEAM family) that are excellent message passing frameworks in the Alan Kay OOP sense.

[shawnz]

There are modern OO languages that stay true to Alan Kay's ideas too. The problem is that they all seem insignificant in impact when compared to Java, which relentlessly sacrifices purity for pragmatism.

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.

[microtonal]

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.

[alecmg]

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

[hopia]

Actor model really is for concurrency, not for parallelism.

For pure parallel computing it introduces unnecessary overhead because of the message passing. That overhead in turn hurts performance, which really is the only reason you'd want to compute in parallel.

[butterisgood]

Parallel compute middleware is often based on message passing when the parallel computer is a cluster. See MPI.

[samatman]

Concurrency allows for parallelism.

It's common to conflate parallel programming with so-called embarrassingly parallel tasks, but this isn't accurate. For tasks which may be executed in parallel but aren't working on different regions of a single state, actors are an excellent choice.

[hopia]

Right, but isn't what you say exactly concurrency instead of what we normally consider parallel computing, at least on a single machine? Depending on the implementation/runtime you may or may not need something like threads, which are a good concurrency primitive, for parallel computing.

[samatman]

I'm not entirely sure what the disconnect is here, but I'll give it a shot.

Parallel computing is simply running more than one aspect of a computation simultaneously, it requires multiple processors/cores, or SIMD. Concurrency is doing more than one thing 'at a time', and this generally includes things like callbacks (to allow more work to be done while waiting on an action) and preemptive threading (which may or may not involve true parallelism).

Concurrency is an opportunity to work in parallel, one which may or may not be achievable. I consider threads a bad concurrency primitive, because they're too low-level and hard to get right, and this becomes even worse when one runs threads in parallel.

Actors, which are a share-nothing concurrency model based on message passing, are a good concurrency primitive. Among the reasons for this are that one can put them on threads and not have to deal with locking and unexpected mutation. You can treat them as an implementation detail that happens below the level the programmer must concern themself with.

This means they're good for running in parallel, as well, which is quite tractable on a single machine given that it has multiple cores (mine has eight).

Colloquially we sometimes say 'parallel computing' when referring specifically to so-called 'embarrassingly parallel' tasks, like some rendering algorithms, where one may bring as many cores to bear on the task as one has available.

But concurrency is always an opportunity for parallelism, and an actor model allows one to take that opportunity given that other aspects of the runtime don't stand in the way. And parallel computing is simply running more than one computation at the same time, it doesn't by itself imply anything else about the algorithm.

[paulddraper]

> it introduces unnecessary overhead because of the message passing.

Inter-process and inter-machine parallelism do that anyway.

[macintux]

Typically parallelism is particularly interesting for performance, and the (usually?) shared-nothing architecture of the actor model is not conducive to high performance computing.

[kevinmgranger]

Shared-nothing usually means a lot of unnecessary copying-- but rust lets you have safe transfers of data ownership, usually without copying. I wonder if that would make for a uniquely performant actor framework. (Depends on the implementation and user code, of course.)

[hopia]

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.

[ahasani]

If you mean by return value like function call, actor actually can send reply message back to the caller provided the called actor knows the caller address

[anthony_doan]

It's a nice approach to concurrency.

It doesn't guarantee parallelization. Concurrency is a precursor and a requirement for parallelization but it doesn't guarantee it.