41–50 of 52 posts
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?
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.
Earlier quoted context omitted.
What do you mean by JavaScript not supporting concurrency? Do you mean parallelism?
I mean exactly what I said. Cooperative threading is still single-threaded. Two things cannot happen concurrently in JavaScript.
Earlier quoted context omitted.
I mean exactly what I said. Cooperative threading is still single-threaded. Two things cannot happen concurrently in JavaScript.
Ah. I have a misunderstanding of definition then, since when I think of concurrency I think of interleaved execution irrespective of whether or not this execution is done in parallel.
This blog is almost unreadable. the font is WAY too thin on Firefox!
Earlier quoted context omitted.
Ah. I have a misunderstanding of definition then, since when I think of concurrency I think of interleaved execution irrespective of whether or not this execution is done in parallel.
I tend to adhere to the dictionary definition of the word, which is two things happening or existing simultaneously. However, I do know that proponents of single-core-bound languages like JavaScript, and others, like to talk about concurrency in a single-threaded way.
> 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.
var state;
if (typeof behavior.init === "function") {
state = behavior.init();
} else {
state = {};
}
Earlier quoted context omitted.
> 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 viewpo…
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.
Earlier quoted context omitted.
Ah. I have a misunderstanding of definition then, since when I think of concurrency I think of interleaved execution irrespective of whether or not this execution is done in parallel.
I tend to adhere to the dictionary definition of the word, which is two things happening or existing simultaneously. However, I do know that proponents of single-core-bound languages like JavaScript, and others, like to talk about concurrency in a single-threaded way.
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.
Earlier quoted context omitted.
I tend to adhere to the dictionary definition of the word, which is two things happening or existing simultaneously. However, I do know that proponents of single-core-bound languages like JavaScript, and others, like to talk about concurrency in a single-threaded way.
The computer science definition of concurrency and parellelism are different that what you're explaining. In CS, a program can only be concurrent. Parallel is to do with how it's run, and the hardware. A concurrent program, is still concurrent even if it's run on a single core, whereas to be considered parallel, it must be running on multiple cores/processors/machines/etc. at the same time. One way to think of it: If…
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.