Live data from Hacker News

Get to Know the Actor Model with JavaScript

monades.roperzh.com

31–40 of 52 posts

Re: Get to Know the Actor Model with JavaScript

#31
post #29
post #8

Earlier quoted context omitted.

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.

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

amen!

Re: Get to Know the Actor Model with JavaScript

#32
post #21
post #18

Earlier quoted context omitted.

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.

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.

If it fails on start you try again and again until it succeeds. There is a submission on the front page that dives in into this: https://news.ycombinator.com/item?id=15182626

Re: Get to Know the Actor Model with JavaScript

#33

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

Slower, poor portability to android/iOS/browser, no typescript/flow (no, those things aren't like typescript or flow), async/await is an afterthought instead of a cornerstone, just because you didn't like an obscure one liner out of context, no thanks.

Re: Get to Know the Actor Model with JavaScript

#34

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

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…

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.

Re: Get to Know the Actor Model with JavaScript

#35
post #21
post #18

Earlier quoted context omitted.

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.

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.

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.

Re: Get to Know the Actor Model with JavaScript

#36
post #29
post #8

Earlier quoted context omitted.

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.

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

As a JS guy - it’s more a newbie programmer thing I think (which obviously there are a lot of in JS).

Re: Get to Know the Actor Model with JavaScript

#38
post #24

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.

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

Re: Get to Know the Actor Model with JavaScript

#39
post #17
post #8

Earlier quoted context omitted.

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

Thanks for that explanation, that makes a lot of sense. See, if that had been included in the original article, I would've grasped it much more quickly, instead of being left wondering if Redux is implementing this pattern or I'm missing an obvious difference, and I'm sure it would've helped others too.

Re: Get to Know the Actor Model with JavaScript

#40
post #29
post #8

Earlier quoted context omitted.

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.

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

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.

Post reply on HN