Get to Know the Actor Model with JavaScript
monades.roperzh.com
monades.roperzh.com
This sounds like Alan Kay's aspirational viewpoint of independent "computers" interacting through messages. Not the object-orientation invented by Nygaard and Dahl in Simula, that introduced objects, classes, subclassing and virtual functions. Kay's vision is not reflected in modern object-oriented languages, while Nygard and Dahl's remain paramount.
The argument that the Actor Model is really a form of object-oriented programming is an unrequired appeal to credibility.
Edit: grammar
I suppose it's not "modern" anymore though - and it doesn't look like swift kept this paradigm.
The threading models on node and browsers do not allow concurrent computation, except for the case of web workers, and the proposed threading additions of JavaScriptCore.
Because of this, the actor model can be overkill when you have no threads. More specifically, you may introduce queuing where no queuing (or other type of synchronization) is necessary. This is because an actor is basically a worker with a work queue (aka mailbox).
For the most part promises can solve most of your async issues. Event emitting/message passing is valuable, but queuing is optional in many cases.
This is correct but misses the point of the article. The idea is to introduce the Actor Model to people unfamiliar with it, using one of the most popular languages out there.
The article is correct but misses the point of the actor model. The idea was to point out that the Actor model is about concurrent computation.
edit: I was reading it on Chrome on Android, it the main text looked gray and had poor contrast. Now I'm on FF 52 on Windows and the text looks black. Weird.
Scala.js, Scala that compiles to Javascript, enabling all of this. https://www.scala-js.org
Try it out !
> It’s easy to screw up immutability in JavaScript, the actor internal state can be modified externally if users of the library are not extremely careful.
Object.freeze() can help prevent this.
return {
...state,
count,
}
The Actor model strongly influenced protypical classes like Smalltalk and therefore also JS.
It’s a 45 year old software design pattern so really it’s better to ask: how does Redux differ from the Actor pattern?
From my understanding, Redux shares the actor/messaging pattern when dispatching events to the reducers, but the state in Redux tends to be centralized (you usually have one main store, but you can create other stores if you want), while in the Actor pattern, each object has it's own state.
Also, in Redux, information flows only in one direction: component => reducer => state. The Actor pattern seems to allow for actors to message each other back and forth.
Actually it's quite opposite. Redux is a library which was created not until 2 years ago and it is used only in JavaScript. Actor model and similar message-passing patterns are in use for decades and not only in JavaScript but in many programming languages. They are popular e.g. in game development for communicating between game objects.
There is this weird viewpoint in JS community that world is turning around JS and its ecosystem, and this is the newest popular library that dictates standards rather than decades of CS knowledge ;)
I never said Redux dictated the standard, I simply asked for the differences, and if it weren't for boobsbr's response, I'd be stuck in a state where I don't know how close Redux was to this model which is quite important to get context and understanding.
> There is this weird viewpoint in JS community that world is turning around JS and its ecosystem, and this is the newest popular library that dictates standards rather than decades of CS knowledge ;)
If you criticize people like this for not knowing what came first, then it's no wonder people feel like that because you'd never give them the opportunity to learn about the lineages. Instead, people will simply think "oh this looks like an interesting paradigm, maybe I'll consider using it in my next project" without realizing that they're already using it.
One of differences could be that Redux has only one object("actor") which can receive messages - that's store.
In actor model there are many actors which can both receive and send messages.
One way to think of it: If I have three plates of food, that I can eat in any order, but it's just me eating, then this is concurrent. In practice, this is no faster than if I had to eat 1, then 2, then 3, however it has the potential to be. By adding another person, it becomes parallel.
Your food metaphor doesn't really work in the computer science sense, because you cannot concurrently eat three things at the same time unless you put them all on the fork at the same time, which is something you simply cannot do in computer science.
The words "concurrency", "multi-threaded", and "parallel" each have different meanings. You can have a program that is multi-threaded but which does not maintain concurrency ie. the output is dependent on race conditions. This is usually, but not always, a bug.
Your confusion stems from the fact that most people do not care about the distinction. You usually don't care about concurrency unless you plan to actually run things in a manner which is unordered. Thus when the theory says "concurrency" you think "parallel". Technically speaking you're wrong, practically speaking your mistake usually won't matter.
As a final example consider a single-core computer running Windows with multiple processes running a myriad of services and programs. At any one time only a single process can run on that single available core, but in practice they are running "at the same time", because the system is implementing a model of concurrency allowing it to schedule and execute the different processes out-of-order.
On topic: I don't see a use case, in which I would need to use the actor model and would pick javascript as my language of choice. However, I do think your article is well-written and explains the actor model quite well.
Javascript is such a mess itself, i don't know how one can explain something in it. Choose python, reads like English.
After looking it up, I don't disagree that Python looks a lot prettier, though: `state = behavior.init() if callable(behavior.init) else {}`
That made me curious if Ruby had anything like Python's `callable`, but I couldn't find anything. This is my best effort in Ruby for aesthetics: `state = if behavior.init.respond_to? :call then behavior.init() else {} end`
In the end, I agree, Javascript looks much worse than the equivalent Python in this case. Unfortunately I don't get a choice of python on the frontend :p
state = behavior.respond_to? :init ? behavior.init : {}
Asking an object if something is "callable" in Ruby is probably unnecesarily verbose, as you are most likely dealing with a method for any attribute access.
var state;
if (typeof behavior.init === "function") {
state = behavior.init();
} else {
state = {};
}