Comment by kjksf | Hacker News Reader

Comment by kjksf | Hacker News Reader

Why does it call itself an "actor" library?

"This actor library runs tasks with the help of fixed number of threads".

This is a M:N user-space scheduler for threads, a re-implementation of what Go provides as part of the language but with 10x the complexity (things that Go doesn't expose: Scheduler, a Task, a SchedulingRule, a Sink, a Filter, a YSPlit and what not).

I'm not a CS historian but this is what Alan Kay complains about when he talks about the pop culture of computer science.

Actor model (https://en.wikipedia.org/wiki/Actor_model) is a somewhat deep idea about structuring systems as independent entities that communicate via sending messages.

A thread is not that. The similarity is superficial.

To the extent that it's about threads that can communicate over channels, it's closer to CSP (https://en.wikipedia.org/wiki/Communicating_sequential_proce...) but as the page says "the two models (CSP and actors) make some fundamentally different choices with regard to the primitives they provide".

It's telling that the only time an actual actor is mentioned is in the name of the library. The actual code talks about tasks, channels, schedulers.

Yes, exactly.

Something might be called an actor if it can:

1) Create other actors at runtime 2) Send and receive messages to/from other actors asynchronously 3) Can do something in response to messages and then optionally change this behavior in anticipation of the next message.

(Meaning: if you have to predefine all "actors" at compile time, this is not actor model. If you have to predefine "exchange points" AKA channels to communicate between two actors synchronously, this is not actor model. If you can't change your behavior at runtime, this is not actor model.)

Actors are very dynamic entities operating in a wild west environment without any guarantees (about delivery, or message ordering, etc -- just like the IP stack). Messages are sent in "fire and forget" fashion. The power of actor model is that it can be useful even in such an environment.

Thank you for the feedback. This helps me a lot in deciding which area of this library needs more explanations. In a followup post I'll show 1) how to create actors run-time, 2) send and receive messages 3) respond to messages. 4) that the messages are async

I don't really think that too many people are aware of Hewitt et al's intentions behind the Actor model - e.g. no global knowledge (emulating a scientific community), actors can only send messages to known acquaintances, only async messages, no need for additional baggage per actor such as mailboxes or lightweight threads. I'm not sure that matters here though.

The author is clearly interested in developing a derivative of Erlang/OTP that works for the author. Erlang is often described as an implementation of the actor model.

I respect the Erlang/OTP model a lot. This library is inspired by that. I don't have the illusion to get anywhere close to it in a reasonable amount of time.

There are also differences to the Erlang/OTP too. This library uses typed messages and taking advantage of the compiler to do type checking. I found it is easier to create this library if 1) the number of input and output channels are fixed 2) the topology of who sends to whom is fixed when the tasks are passed to the scheduler.

The author here. Thank you for the feedback. I take it as my failure explaining what this library is about. I will write a followup post to explain why I think this library supports an actor-like programming model.

Reply on news.ycombinator.com