Live data from Hacker News

Message Passing and the Actor Model

dist-prog-book.com

31–40 of 88 posts

Re: Message Passing and the Actor Model

#31

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…

The actor model may not help much with overall system comprehensibility. But it can help a lot with comprehensibility of the pieces.

A HTTP request handler may send messages (and wait for responses) to get all the data it needs, instead of taking mutexes and getting the data directly. The actors responding to the data fetch requests will generally be pretty simple -- get a request, grab the data and return it (and handle writes as necessary); if they bottleneck, it's either too many requests or the underlying storage is too slow. If your request handler bottlenecks, you probably have a slow data fetcher, the handler's data processing is too slow, or you're making a lot of data requests sequentially instead of concurrently.

You absolutely need to have good instrumentation to understand your system -- at a minimum you need to know the queue lengths for at least important actors; having queue processing rate is pretty useful too.

Re: Message Passing and the Actor Model

#32
post #18

Earlier quoted context omitted.

Personally I'm not too fond of Pony's take on the actor model. I believe it is in the models core that every actor is in total control of their own behavior, and the only interaction is via messages that can be interpreted as the receiver pleases. In Pony, it is the sender that directly commands the receiver what it will do next (via function calls/behaviors).

My take is that you are looking at it the wrong way. Pony uses a single message queue for each actor (which is completely invisible at the code level) and typed messages (which syntactically look like functions). Behaviors (the message handlers) have a lot of limits on them compared to functions (like no return values), so it really is message passing. I'm not sure I really like the syntax that makes messages look li…

> Pony uses a single message queue for each actor (which is completely invisible at the code level) and typed messages (which syntactically look like functions).

I totally agree with this definition but believe that it leads to awkward programming. The problem stems from forcing the message queue to be FIFO, which does not always make sense. I think the Erlang style selective receive is the correct abstraction, as it avoids having to maintain a separate queue in userland. I understand why Pony didn't go down that road though, we have a lot more shared experience in type systems for function calling compared to message passing.

Re: Message Passing and the Actor Model

#33

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 too ended up replacing all channels with a mutex or two in a small web socket relay server in Go, and things became 10x easier to reason about.

I think part of the problem is the lack of usage/support for channels in the Go stdlib itself (seems that the stdlib authors also prefer mutexs). The other issue with sending a close msg on a channel to let the consumer know there will be no more messages, and that an error is thrown if you write to a closed channel.

Re: Message Passing and the Actor Model

#34

Earlier quoted context omitted.

I wish I could target the browser too. Like my biggest problem is writing a front-end and backend in two languages. If I could do both in one, that would be such a killer feature.

Clojure and ClojureScript let you do this (albeit in Clojure)

IIRC, there is an implementation of Go that compiles to Javascript. https://github.com/gopherjs/gopherjs

I have been meaning to give it a try, but so far I have not found a good excuse to.

Re: Message Passing and the Actor Model

#35

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…

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.

Re: Message Passing and the Actor Model

#36
post #28

Earlier quoted context omitted.

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…

>It's worth mentioning that this isn't the only way to do distributed programming. 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' ..

I don't think that's true. Ericsson used it at one point. What makes you think every single train in the "Western world" uses it as well?

Re: Message Passing and the Actor Model

#37

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…

I checked the tutorials section on Legion's site, they don't seem to be very inviting for a stranger. Is there a better site that would help me grasp basic ideas about Legion and show its strengths in comparison to other paradigms?

Re: Message Passing and the Actor Model

#38

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…

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!

Re: Message Passing and the Actor Model

#39

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…

Having worked on fairly concurrent systems in Erlang specifically, I would say one of the most useful tools to understanding the behavior of the system is the tracing facilities. Even something as limited (but user friendly) as ErlyBerly[0] helps a lot.

As you scale up the number of concurrent processes who need to engage in ad-hoc concurrency, message passing becomes (in my experience) the only feasible way to manage those interactions. Being able to insert yourself in-between the communicating processes becomes necessary to truly understand what your system is doing.

This is true even outside of Erlang itself, such as deploying independent OS processes that use HTTP for communication. Wireshark has definitely been my friend.

State charts, interaction diagrams, and sequence diagrams are also invaluable.

[0]https://github.com/andytill/erlyberly

Post reply on HN