I feel like it's a more general problem: Actors are imperative. So all these simple patterns are not composable.
When you perform something like "I need to do smth with future and then change state of actor", you have a plenty of solutions. Piping, actors per requests, request ids, etc. But when you, for ex., have two actions in an actor that should be chained, and messages inside each should be stashed and then unstashed at once, things getting weird. What I mean: - "stashing" is an effect - "persistence" is an effect - "future resolution" is an effect - "actor state change" is an effect It's not a functional paradigm. Being inside an actor, you're forced to be imperative. But, given that we have scalaz and learned all the good books, why can't we extract the effects and make some functional layer above actors? akka-stream does great job there. But what about state? What about all this mess of effects? What I need is a State monad, but async and with built-in event sourcing support. On Tuesday, May 19, 2015 at 1:30:27 AM UTC+3, Andrew Gaydenko wrote: > > Дмитрий, > > In this topic > > https://groups.google.com/forum/#!folder/current/akka-user/R1ZxPKlp1fI > > *Michael Frank* has suggested an idea, I have implemented it, and it does > work at my use case as expected. Probably, you will get something useful > there also :) > > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
