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

Get to Know the Actor Model with JavaScript

monades.roperzh.com

Post reply on HN
Print view View original

11–20 of 52 posts

Re: Get to Know the Actor Model with JavaScript

#11

Post by datashaman »

kevmo314 wrote: post #8
abritinthebay wrote: post #7

Earlier quoted context omitted.

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?

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.

There is a much larger world outside the tunnel created by React.js and its ilk.

Re: Get to Know the Actor Model with JavaScript

#12

Post by badminton1 »

roperzh wrote: post #5
badminton1 wrote: post #4

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 beca…

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.

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.

Re: Get to Know the Actor Model with JavaScript

#13

Post by xsmasher »

aryehof wrote: post #9

> "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'…

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.

Re: Get to Know the Actor Model with JavaScript

#14

Post by boobsbr »

roperzh wrote: post #5
badminton1 wrote: post #4

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 beca…

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.

Please increase the contrast of the main text, it's uncomfortable to read.

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.

Re: Get to Know the Actor Model with JavaScript

#15

Post by bsimpson »

spraak wrote: post #10
bsimpson wrote: post #3

Earlier quoted context omitted.

I'd also have liked to see destructuring used to set the new state: return { ...state, count, } I realize that it's superfluous when count is the only property on state, but it makes the code both easier to understand and to maintain as state gains new properties over time.

I've more often seen that called "property value shorthand", but it does compliment destructuring

I probably should have said spread. My inner monologue thinks of ... as destructuring, even though I intellectually know they are distinct.

Re: Get to Know the Actor Model with JavaScript

#17

Post by boobsbr »

kevmo314 wrote: post #8
abritinthebay wrote: post #7

Earlier quoted context omitted.

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?

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.

The article is focused on explaining the design pattern, while Redux is influenced by the 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.

Re: Get to Know the Actor Model with JavaScript

#18

Post by mercer »

innocentoldguy wrote: post #16

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.

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.

Re: Get to Know the Actor Model with JavaScript

#19

Post by bsaul »

xsmasher wrote: post #13
aryehof wrote: post #9

> "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'…

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.

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

Re: Get to Know the Actor Model with JavaScript

#20

Post by tskaiser »

innocentoldguy wrote: post #16

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.

What do you mean by JavaScript not supporting concurrency? Do you mean parallelism?
Post reply on HN