
Get to Know the Actor Model with JavaScript - roperzh
https://monades.roperzh.com/get-to-know-the-actor-model/
======
aryehof
> "If this sounds to you a lot like Object-Oriented Programming (OOP), you are
> right."

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

~~~
xsmasher
Objective-C has the message-passing approach to object-oriented programming;
all dispatch was at run-time, and an object could delegate any unrecognized
messages or decide for itself how to respond to them.

I suppose it's not "modern" anymore though - and it doesn't look like swift
kept this paradigm.

~~~
bsaul
ironically, swift is aiming at implementing actor concurrency for its next
versions (even adding an "actor" keyword).

------
partycoder
The actor model deals with concurrent computation.

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.

~~~
roperzh
Hey, article author here, thank you for passing by!

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.

~~~
partycoder
Hey, Scala/Akka user with many years of experience here, thanks for replying!

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.

------
walkingolof
There is a Javascript "port" of Akka , called Akka.js
[https://github.com/akka-js](https://github.com/akka-js)

Scala.js, Scala that compiles to Javascript, enabling all of this.
[https://www.scala-js.org](https://www.scala-js.org)

Try it out !

~~~
imafish
+1 for Scala.js mention. That project is really awesome.

------
kevmo314
How does this differ from a Redux-type store besides being able to instantiate
them on demand instead of having a global state?

> 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.

~~~
abritinthebay
It’s a pattern. It’s not supposed to be Redux/whatever library. It’s a pattern
of writing code (like MVC, or Pub/Sub, etc)

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?

~~~
kevmo314
Sure, that's fine too. My point is more that it would've been nice to get a
summary of the differences instead of requiring the reader to dig through the
article, since Redux is much more prevalent. Even after digging, I still can't
tell if there is a difference. If there is none, it would've helped greatly to
explicitly say this.

~~~
hex13
> since Redux is much more prevalent.

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 ;)

~~~
kevmo314
Based on what shows up on the front page, I'd say the average reader is way
more likely to be familiar with Redux than the actor model.

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.

~~~
hex13
> I simply asked for the differences,

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.

------
innocentoldguy
I think a better language to understand the Actor Model with is Elixir. The
Actor Model's main point is concurrency. It is hard to demonstrate that in a
language that doesn't support concurrency.

~~~
mercer
Don't forget fault tolerance! In my particular use cases concurrency is not
really necessary, but I love the fact that I don't have to be quite as
'defensive' in my programming. Whenever a particular (Erlang) process/'Actor'
fails, its supervisor can simply restart it and I can deal with the cause of
failure later while the entire system chugs along (mostly) happily.

~~~
sprt
What happens when the process is bound to fail on start? (eg. trying to bind a
port that's already being used) Never used that model so I'm curious.

~~~
mercer
It depends on how you set things up, but one possible approach is that the
supervisor, after a few retries, would _also_ shut down, which would trigger
the supervisor _above_ that to restart the whole thing with a different port.
This wouldn't make sense, probably, but maybe it illustrates how you can go
about these things.

------
prodtorok
For those who like to learn from videos, here is an interview/lesson from Carl
Hewitt (he introduced the model):

[https://www.youtube.com/watch?v=7erJ1DV_Tlo](https://www.youtube.com/watch?v=7erJ1DV_Tlo)

------
kroltan
This blog is almost unreadable. the font is WAY too thin on Firefox!

~~~
neurotrace
Looks fine to me. Firefox 55.0.3 on Windows 10.

------
imafish
Jesus! Are there any posts on HN these days that are not JavaScript or
blockchain? (or a combination, describing 90% of blockchain projects....)

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.

~~~
Can_Not
Just checked the top 90, there are 2 block chain/cryptocoin posts and 2
JavaScript posts. Did you miss the other 86?

------
Dolores12
> let state = typeof behavior.init === "function" ? behavior.init() : {};

Javascript is such a mess itself, i don't know how one can explain something
in it. Choose python, reads like English.

~~~
faitswulff
It's not unique to javascript. The equivalent in ruby would be `state =
behavior.init.class = Method ? behavior.init : {}`

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

~~~
jack_jennings
Closer to idomatic Ruby:

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.

------
lotusko
yes,I like this design,and my system has applied it.I feel this theropy just
like the domain-specific languague or system thought(the_Fifth_Discipline).
best regards

