First you state an actor can only create other actors or send messages, but then it appears they can check whether other actors are alive and retarget messages to other actors. How do they healthcheck other actors if they don't wait for the response and only send messages in "fire and forget" manner?
Although actors are asynchronous and don't have to wait for other actors, their state changes may rely on conditions from other actors. If there is a circular dependency between actors, then they can deadlock each other.
Thanks for the video. Could you please set up BAT payment for your website, finematics, so that I can make contributions while learning stuff posted there?
There should be no actor's mailbox overflowing as there are not so many messages which can be sent to an actor. In any case the number of messages can be optimized by the system optimization.
Let's say, I have counter and a button. When I perss the button (one actor), I send message to counter (another actor) about this event. This two actors have different identities. If I add another button into UI, I'll have two actors with same identities (they're both buttons and respond to click), but they will have different internal state (hovered, pressed, idle) and different addresses. If we take implementation of this system in HTML, we will have two HTMLButtonElments (identity) inside our DOM tree (system) with different addresses (e.g position inside DOM tree)
@@Fridrih123 Aren't you mixing up identity with "type"? Two buttons on a page are both of type "" , but do not have the same identity. Of course with HTML it is somehow ambiguous what exactly "identity" means if no "id" attribute has been specified, but then I would argue that the address is actually part of the id (even everything else about both buttons is the same and they do not have an "id", then we can still identify them by their location in the tree). Now going back to the original comment, I too think that the sentence at hand was a bit confusing. A better wording would have been: "two (or more) addresses can point to the same actor".
> actors are lightweight and it's easy to create thousands or even millions of them as they require fewer resources than threads NOT TRUE! for actors to be asynchronous they must be implemented using threads or processes (preferably using threads). That's how asynchronous processes work! actors by logic do NOT consume less resources than threads as its just an abstraction. anyways i'm not listening to rest of this nonsense
Excellent explanation. Concise and unambiguous.
Thanks! High level model, short and informative. Such videos are the best!
This has to be the best explanation! Clear and concise!
Which means you do not get the concept either, cause he doesn’t.
Not Elixir, but Erlang, give credit where credit is due.
Perfect Level of information passed to understand the concept, Great Job :)
Thanks!
@@Finematics It will be great if you also make a video on Spring framework. I'm waiting :)
Thanks for a new learning
many thanks for posting this explanation .
First you state an actor can only create other actors or send messages, but then it appears they can check whether other actors are alive and retarget messages to other actors. How do they healthcheck other actors if they don't wait for the response and only send messages in "fire and forget" manner?
Thanks Dude. Awesome video.
Magnificent explanation
perfect video to easily understand the actor model
Hello. Your explanation is very good. Thanks!
Thanks a lot!
Is there any chance to see a CSP explaination in near future?
I understood how CSP work in clojure through a rich hickey's video. He explains it like a CS god, in full glory
Great and clear explanation, thanks!
Great job! Thanks mate!
What about Erlang? Is there some dispute that Erlang uses the Actor model?
Elixir is built on BEAM, same as Erlang, they are fairly similar.
Elixir and Lisp Flavored Erlang are just different frontends for Erlang. They all use the actor model.
Really informative, thanks¡
Thank you!
Very well explained. Thanks
why cant we use spring cloud technologies instead of Actor model ?
how is code reuse usually implemented in the actor model?
By breaking it into a single responsibility functions.
@@aammssaamm interesting, thanks. could you provide an example please?
@@lulu4882 Excuse me?
@@aammssaamm an example of actors sharing a single responsibility function.
Great explaining!
Awesome vid
Great video!
GOOD JOB!! ❤️💪🏻
Thanks
Great explanation :)
best explanation! really appreciate this.
Thanks!
Thanks !
best🔥
Sounds very similar to goroutines in terms of the theory. Anybody know the diff?
also similar to javascript event loop
awsome~
umm.. how actor model susceptible to deadlock?
Due to no usage of locks at all
Although actors are asynchronous and don't have to wait for other actors, their state changes may rely on conditions from other actors. If there is a circular dependency between actors, then they can deadlock each other.
You forgot about Erlang, GParS and Kotlin
fantastic +1
thank you
Thanks for the video. Could you please set up BAT payment for your website, finematics, so that I can make contributions while learning stuff posted there?
done, better late than never
the term of mailbox is not a requirement for the actor model
Thanks for the video man. I found it really helpful for my friend with his course project so he doesn't need to read an akka book. 😁
Tip: he probably should
sweet
Actor models are good looking people who can act.
seems a lot like how processes are implemented in Elixir, I could be wrong :P edit: oops I missed the ending
This is certainly what I don't need
this sounds like Abramov
It’s mind-boggling that people produce content about the actor model without mentioning the Pony programming language.
There should be no actor's mailbox overflowing as there are not so many messages which can be sent to an actor. In any case the number of messages can be optimized by the system optimization.
Correct. The Actor Model can be susceptible to mailbox overflowing, but with a proper implementation this issue can be mitigated and never occur.
@@Finematics Sorry, you don't seem to understand the topic.
Interesting. I'm looking forward to your explanation of the topic.
“two actors with the same identity can have different addresses”
why do two actors have the identity?
Let's say, I have counter and a button. When I perss the button (one actor), I send message to counter (another actor) about this event. This two actors have different identities. If I add another button into UI, I'll have two actors with same identities (they're both buttons and respond to click), but they will have different internal state (hovered, pressed, idle) and different addresses.
If we take implementation of this system in HTML, we will have two HTMLButtonElments (identity) inside our DOM tree (system) with different addresses (e.g position inside DOM tree)
@@Fridrih123 Aren't you mixing up identity with "type"? Two buttons on a page are both of type "" , but do not have the same identity. Of course with HTML it is somehow ambiguous what exactly "identity" means if no "id" attribute has been specified, but then I would argue that the address is actually part of the id (even everything else about both buttons is the same and they do not have an "id", then we can still identify them by their location in the tree).
Now going back to the original comment, I too think that the sentence at hand was a bit confusing. A better wording would have been: "two (or more) addresses can point to the same actor".
So, Erlang.
> actors are lightweight and it's easy to create thousands or even millions of them as they require fewer resources than threads
NOT TRUE!
for actors to be asynchronous they must be implemented using threads or processes (preferably using threads).
That's how asynchronous processes work!
actors by logic do NOT consume less resources than threads as its just an abstraction.
anyways i'm not listening to rest of this nonsense
The video would have been even nicer if the host wasn't chewing bubble gum
1
Thanks for the explanation but please do not chew gum while talking, it's disgusting
Message is not explained.
Hi Anne, in this context a message is just a simple piece of data (any data) that is usually send to a specific recipient.
@@Finematics But you don't understand how exactly it works.
Looking forward to your explanation what a message in the Actor Model is
Still looking forward to Anne's video :D
@@flogginga_dead_horse4022 Sorry, I do not work for free.
thanks
“two actors with the same identity can have different addresses”
why do two actors have the identity?