<sarna>
I'm reading this one at the moment, but I'm not sure if it applies to pony
<SeanTAllen>
sarna: pony is somewhat different
<SeanTAllen>
i'm not aware of a good blog series really
<sarna>
:(
<SeanTAllen>
all of them that i see are specific to a given implementation
<sarna>
time to write one :^)
<SeanTAllen>
the basics that are shared across all is...
<SeanTAllen>
1) actors communicate through messages
<SeanTAllen>
2) you send messages from one actor to another in an async fashion (some implementations provide a way to write code that looks synchronous)
<SeanTAllen>
3) mutable data can't be shared between actors
<SeanTAllen>
4) there's some sort of schedulers that determines when an actor runs
<SeanTAllen>
beyond that, there's not a lot in common between erlang, pony, akka
<sarna>
shucks
<SeanTAllen>
for example...
<SeanTAllen>
erlang has the concept of selective receive
<SeanTAllen>
this means that messages can arrive as 1, 2, 3
<sarna>
do pony actors even have mailboxes? I mean isn't it just executing behaviors
<SeanTAllen>
and you could use selective receive to read message 2 first
<sarna>
Oo
<SeanTAllen>
whereas in pony, you have to handle them in the order they are received
<SeanTAllen>
there are pros and cons of each approach
<SeanTAllen>
yes, each pony actor has a queue that generally gets referred to as its mailbox
<SeanTAllen>
calling a behavior is a message send in pony
<sarna>
can I see it? modify it?
<sarna>
the queue
<SeanTAllen>
no you can't see it
<SeanTAllen>
no you can't modify it
<sarna>
alright
<SeanTAllen>
messages are processed in order by an actor
<SeanTAllen>
this provides causal guarantees that can be very handy
<SeanTAllen>
feel free to ask any questions you have though and i'll do my best to answer
<sarna>
how would I model the famous bank accounts example?
<SeanTAllen>
well, aside from the fact that that isn't how bank accounts actually work...
<sarna>
:)
<SeanTAllen>
i would have an actor for each bank account.
<SeanTAllen>
i would send a message that is something like initiate transfer from one account to another, with an amount.
<SeanTAllen>
that transfer is pending until it is acknowledged by the other account
<SeanTAllen>
then you have to decide...
<SeanTAllen>
what are the rules of your bank for how long a transfer can be outstanding before its cancelled
<SeanTAllen>
for example, i used to send my father money every month. he passed away, 90 days after the last check he didn't cash was sent, my bank cancelled it and the $ was returned to my account
<SeanTAllen>
until that time it wasn't available
<SeanTAllen>
of course, that leaves open...
<SeanTAllen>
what happens if the other account accepts it at the same time we decide its no longer valid...
<SeanTAllen>
then you'd have to do something to work that out
<SeanTAllen>
but we are now modeling accounts in a way that ... reflects the real world and has to deal with the distributed, async nature of it.
<sarna>
would I need something like a main actor? The Bank? I guess I don't?
<SeanTAllen>
No
<SeanTAllen>
you don't
<SeanTAllen>
you probably dont want to have 1
<sarna>
that's good
<SeanTAllen>
because "the bank" might become a bottleneck
<sarna>
yup
<SeanTAllen>
you want each actor to be able to act as individually as possible
<SeanTAllen>
if you want to maximize concurrency and possible performance