21–30 of 88 posts
It has not seen a lot development over the past ... couple of years, but it worked quite nicely when I last tried it.
I haven't given myself the opportunity to sit down and play with an actor model. But in the meantime, despite reading literature such as this, I have trouble envisioning what it actually entails day-to-day. I think of my experience with channel-based communication in Clojure, Go, and even Rust's mpsc. And every time I feel an instant feeling of debt because I know I'm just one or two more channels away from misunders…
One suggestion for actors is to look at the actors as elements of serialization, rather than as elements of concurrency.
> 59 minutes read Is this actually correct? I am inclined to think not but it is difficult to judge just from scrolling through it quickly.
I haven't given myself the opportunity to sit down and play with an actor model. But in the meantime, despite reading literature such as this, I have trouble envisioning what it actually entails day-to-day. I think of my experience with channel-based communication in Clojure, Go, and even Rust's mpsc. And every time I feel an instant feeling of debt because I know I'm just one or two more channels away from misunders…
A typical example of how it gets applied might be a web server, where each HTTP request is handled by its own process, and potentially delegating multiple tasks concurrently to other processes in the background which handle queuing and executing work associated with that request. You might have pipelines of processes, each responsible for some specific task/transformation before handing off work to the next stage in the pipeline. On top of that Erlang/Elixir provide supervision, where components of the system are started/monitored by a special process type called a supervisor, which will restart its children when failure occurs, and if a set of conditions fail, will itself be restarted by its parent supervisor. So your application ends up structured as a tree of supervisors and worker processes, where components of the application are branches of the tree, and can be isolated from the failure of other components.
Hopefully that helps give you an idea of how the model plays out in practice. I would definitely recommend playing around with either Erlang or Elixir, they are a lot of fun, and it really changes the way you think - at least it did for me.
I was hoping to see a mention of Pony which looks like a promising language based on the actor model.
Not sure whether or not Pony will make it in, but I will definitely think about it more. It is really interesting to see a new actor-model language being developed. I also see that there have been a couple of papers written about Pony, which is a good sign. Definitely on my radar for the future, but I still need to learn more about it.
Is there an index to this book I'm not seeing? I see the directories, but not seeing an overall index. A bit hard to navigate.
If you click on "Chapters" it takes you to a directory listing of the chapters, click on a chapter link and it takes you to another directory listing of pages. Click on a page link and it takes you to an actual chapter. It appears that the "book" still needs a fair amount of polishing to be navigable.
I haven't given myself the opportunity to sit down and play with an actor model. But in the meantime, despite reading literature such as this, I have trouble envisioning what it actually entails day-to-day. I think of my experience with channel-based communication in Clojure, Go, and even Rust's mpsc. And every time I feel an instant feeling of debt because I know I'm just one or two more channels away from misunders…
In my personal opinion, message passing is going to be considered an evolutionary dead-end in the long term, and these sorts of more intuitive programming models based on generating dataflow graphs automatically will become more dominant.
Disclaimer: I work on Legion.
I haven't given myself the opportunity to sit down and play with an actor model. But in the meantime, despite reading literature such as this, I have trouble envisioning what it actually entails day-to-day. I think of my experience with channel-based communication in Clojure, Go, and even Rust's mpsc. And every time I feel an instant feeling of debt because I know I'm just one or two more channels away from misunders…
It's worth mentioning that this isn't the only way to do distributed programming. Dataflow programming works quite well, and the newest state of the art systems are exploring ways to generate dataflow parallelism implicitly from sequential programs. See e.g. Legion from Stanford: http://legion.stanford.edu/ In my personal opinion, message passing is going to be considered an evolutionary dead-end in the long term, an…
Its not the only way, but it is one of the oldest that is still in production.
If you take a train anywhere in the Western world, your life is being protected by best x-of-x systems based around the actor model.
Just sayin' ..
The article doesn't mention [Vert.x]( http://vertx.io/ ), another JVM library/framework (also works outside of the JVM with Javascript for example) that is loosely based on the actor model. And now with Kotlin coroutine support, they've managed to abstract away a lot of the nodejs like callbacks that clutter up your code - you still need to be aware of what's happening wrt callbacks and such, but it makes your code a…
I haven't given myself the opportunity to sit down and play with an actor model. But in the meantime, despite reading literature such as this, I have trouble envisioning what it actually entails day-to-day. I think of my experience with channel-based communication in Clojure, Go, and even Rust's mpsc. And every time I feel an instant feeling of debt because I know I'm just one or two more channels away from misunders…
At first it's simpler with actors to think concurrently mainly because of the strict message passing rule for communication. But as your logic become more complex it will become hard to understand as the code flow is artificially separated between different entities, that doesn't scale nor compose easily.
That's being said, it can be powerful to have just some top level actor abstractions that encapsulate more common idioms.
Actors are great to build distributed micro services, you can have a supervisor to monitor and restart services, a registry to discover and subscribe. An actor can represent a service of course. Very useful as high level concurrency abstractions, not so much as low level primitives.