Great article!

What do you use to for the diagrams?

Let’s imagine we have an actor that behaves like a calculator and that its initial state is simply the number 0. When this actor receives the add(1) message, instead of mutating its original state, it designates that for the next message it receives, the state will be 1

this does not make sense to me, so does the actor change its internal state or not?

The only identity of the Actor is the mailbox. Actors have something called a "become" statement; this defines the behaviour and state of the object behind the mailbox. So when an Actor with state 3 receives an "add(1)" message it "becomes" a new object with state 4 to process the next message. This is related to lazy-list programming in functional languages which allow state changes in languages that are immutable. The Actor model does in fact enable concurrency for non-mutable operations, where a "become" can be actioned before processing the message (to perform some computation).

Really interesting article! Could you elaborate this part, please?

> Let’s imagine we have an actor that behaves like a calculator and that its initial state is simply the number 0. When this actor receives the add(1) message, instead of mutating its original state, it designates that for the next message it receives, the state will be 1.

How and when does the actor mutate its internal state? Thank you!

So if I just use one queue with producers and consumers in RabbitMQ I can replicate de Actor Model in any language. We was already using this pattern and just didn't know it's name lol.

using a rabbitmq queue does not match the actor model my friend. There is a subtle difference. Actors message each other "DIRECTLY". An actor knows the address of the actor it is messaging. This is a key element. In rabbit mq case the producer just knows about the message queue and knows nothing about who will consume.. i.e it does not know reference/address of any of the consumers.

Revisit the One ant is no ant section of the article.

How does it know the actor? Through some mailbox? If so, can't we say that 'queues' are mailboxes? Or 'dark boxes'. As the article says, you don't care where the actor lives. Perhaps you also don't have to care who the actor is?

Oh, good point, thanks for the answer. I hadn't quite understood that before. This message exchange serves to share data between processes without data races I suppose

Shouldn't it be:
"that is basically what Erlang calls its actors"
?

Nice

Thank you for posting this.

Can the programming be helpful for embedded systems

Great post! Short and sweet :)

Awesome article. Looking forward for more.

it's clear and concise. thank you for your effort

well explained. Thanks

Edit - 'whose' only responsibility is to know what to do when this crash happens.
Nice Article BTW

Well written

Well explained.Thank you

very gooood and useful post , thanks

Hello

Thank you for this explication.

I have one more question. In order to model an application with actor model stackoverflow 's members have advised to use the communication diagram ( http://www.uml-diagrams.org... ).

But i don't understand how to model the creation of actor with this model.

any suggestions or links on this would be helpful.

best regards

Note that a communication diagram corresponds with a sequence diagram, and a sequence diagram includes the idea of a "life line" for the participant. I use that, along with a message of "create", to represent creating a child.

Thank you for a compact intro in actor based languages.
I have a question can deadlock still occur in actor based languages (for example in scala or elixir).if yes how to detect and avoid them ?any suggestions or links on this would be really helpful.

very good!

Clear and good explanation, thanks a lot.

Well explained .. Thanks !

Concise and crisp. Great post !!

Really great post, direct. Thanks for video too.

So clearly articulated. Wish all technical articles were this. "Lagom" - just enough - no more no less.

You open my eyes. I was struggling to understand it for weeks.

Good introductory post, although I think perhaps the sentence "Think about it, if an actor is just this unit of code with a mailbox and an internal state" is a bit misleading. If you have multiple instances of the same actor, i.e created via a router, and those actors have "internal state" then it really depends on the actor implementation as to whether you really care about which instance you are talking to.

Actors that are designed to be stateless, similar to the concepts of a RESTful service, are better suited to be distributed, especially when a number of actors are coordinating together to accomplish some final task.

REST isn't about stateless services. It's about stateless communication. Both client and server are stateful

Hi, good POST!!

I like this video on how to put actors in action (and show the difference with parallelism/threads)

https://www.youtube.com/wat...

Concise!

Thanks! Those 10 minute blog posts really come to the point - I love it.

awesome!

Good one