Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Message Passing and the Actor Model

dist-prog-book.com

Post reply on HN
Print view View original

41–50 of 88 posts

Re: Message Passing and the Actor Model

#41

Post by napsterbr »

bitwalker wrote: post #24
always_good wrote: post #20

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…

I would spend some time experimenting with Erlang or Elixir. The thing that really made the actor model "click" for me was how each actor in Erlang is just a process (green thread basically). The only way to communicate between processes/actors is message passing, and the way you end up constructing software is by modeling individual tasks and responsibilities of your application in terms of processes. The way proces…

Hey, off topic but I have to say this, we use a bunch of libraries authored / maintained by you. Thanks!

Re: Message Passing and the Actor Model

#42

Post by [deleted] »

always_good wrote: post #20

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…

[deleted]

Re: Message Passing and the Actor Model

#43

Post by k__ »

bdavisx wrote: post #19

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…

Vert.x is still going? Nice!

Used it back in the days for a game backend, because of the promised better-than-nodejs-performance and multithreading.

Re: Message Passing and the Actor Model

#44

Post by Jtsummers »

always_good wrote: post #20

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…

Actors are computers and computers are actors. The mapping from actor to physical computer is sometimes one-to-one, sometimes many-to-one. An actor is an entity capable of handing input, changing its internal state, sending output, and potentially creating new actors.

Whether we use it explicitly or not, the reality is that many of our systems can be modeled as actors in this sense. Whether you're using erlang (very explicitly based on the actor model), or C with pthreads and mutexes, you can model your system as actors. The specific mechanism of communication is irrelevant. And this is where I find it useful. My day job is in embedded systems. We have clear actors (multiple radios communicating over a protocol) which we treat as actors from a design perspective (of that protocol). Internal to each radio we have a number of physical computers running concurrently and communicating over a bus which acts like a shared memory. For this internal part, actors are not how it's coded. However they offer an effective model for how things work, as we can isolate the communication parts to a handful of modules (per application running). So from the internal part of our application it is as if we are sending messages (though the reality is we're writing them to a shared memory and setting some flags) and it is as if we are receiving messages (though the reality is we're reading from a shared memory when some flag goes high).

Re: Message Passing and the Actor Model

#46

Post by Joeri »

always_good wrote: post #20

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…

I just finished implementing an akka system. I was tasked to build an event-driven auto-scaling self-healing and self-balancing clustered rule processing engine, and I knew intuitively something like akka was needed.

The learning curve in the beginning was frustratingly steep, and imho the only way to really grok akka is to implement something significant with it. I still feel I haven’t fully grasped its nuances, but eventually it became almost as routine to model everything as actors and messages as it was to model rest api’s with models and controllers. It’s a different way of thinking.

Akka actually uses futures, when you “ask” an actor (send a message and receive the promise of a reply).

I would say the primary benefit akka offers is changing the level of abstraction and forcing a proper modelling of the logic as message pipelines.

Re: Message Passing and the Actor Model

#47

Post by Latty »

always_good wrote: post #20

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…

I've played with this a bit, professionally and personally (Scala/Akka specifically).

The way it makes you think about your model and the boundaries it introduces seem good. I really love the way it forces you to model the communication between parts of your code as a data structure - it feels like a much less costly version of the "everything as a micro-service" dream.

Scala seems like the ideal language for it - you need really simple, powerful data types for it to feel good, otherwise those messages become painful to make or get overloaded in bad ways.

Akka was still struggling with type loss in the system the last time I used it, which really felt like a pain, and where I feel it adds the boundary that makes it harder to understand.

Re: Message Passing and the Actor Model

#49

Post by noelwelsh »

uryga wrote: post #38
noelwelsh wrote: post #35

Earlier quoted context omitted.

Having been involved in some systems that make heavy use of actors I 100% agree. We call actors "concurrent gotos" as they bring all the "advantages" of gotos with the added "benefit" of concurrency. It's a very primitive model of concurrency, only slightly better than mutexes. There are much better models in the research community but few of the ideas have yet made it into usable systems.

Could you give some references to those better models? Sounds interesting!

Very briefly:

Process calculus, such as the pi-calculus and join calculus. Prototype implementation in Scala here: https://github.com/Chymyst/chymyst-core

Lasp and Bloom: http://christophermeiklejohn.com/lasp/2018/03/02/lasp-vs-blo...

Post reply on HN