On Mon, Mar 10, 2014 at 9:11 AM, Roland Kuhn <goo...@rkuhn.info> wrote:
> BTW: almost all Future combinators are not concurrent (as in > nondeterministic), Futures are therefore very useful for modeling > parallelism without the concurrency pain. I invite you to scrutinize the > scala.concurrent.Future API for non-determinism and then see for yourself > how that is reflected in the types. > Stating the obvious for Dr. Roland Kuhn :-), but in my opinion the difference between a Future[T] and an ActorRef is that actors are too low-level and general, whereas Future[T] is very specialized - the Future combinators simply assume that Future is a container for a Try[T] result that will be available either now or in the future, the actual moment being of no consequence for the combinators that simply guide you through the happy path. The problem with Future[T] is that it can't be applied for example on problems where streams and/or bi-directional communications are involved. An ActorRef can provide an awesome implementation for Future[T] instances. However, between an ActorRef and a Future[T], there is a need for abstractions in-between. I know there are already patterns and best practices for designing stuff with actors, but whenever I work with actors, somehow I always end up with fragile and tightly-coupled designs, precisely because I had to deal with low-level stuff. E.g. actor A sends a message to actor B, but actor B could crash, so now you're thinking of using an external queue that persists messages for actor B's return. But once that external queue is operational, now you're thinking of redundancy for actor B, so you actually want actors B1 and B2, but because you designed actor B as statefull, now you're thinking in terms of primary / backup nodes and maybe you want those messages to not be pulled out of that queue unless they were processed in a reasonable amount of time by the primary actor, or otherwise have a backup that takes over that responsibility. Or maybe you have stateless B actors, so round-robin dispatching is not a problem, yet the message processing itself is long and could crash, so maybe you want to try again later with another actor in case it didn't finish in a reasonable amount of time. Then you realize that actor A should maybe send the same or different messages to different actors, but then you realize that this is actually tight coupling and you actually want a channel on which actors could subscribe for the messages they are interested in. Or maybe you want your cluster to scale depending on the load, so you want to create actors dynamically depending on runtime stats, yet this is a far cry from bringing up HTTP servers dynamically in an AWS ELB environment, because it's more generic and those docs give me the creeps. Somewhere in that process, my head explodes, especially given that I haven't solved the first problem I always have, which is good future-proof design, because actors don't guide your implementation at all and many times it's totally non-obvious of what to do. Kudos on debating the deprecation of "sender". That's a step in making that interface more solid. I also await eagerly on your Reactive Streams - I do feel the need for an Rx streams implementation that also does back-pressure. -- Alexandru Nedelcu www.bionicspirit.com PGP Public Key: https://bionicspirit.com/key.aexpk -- >>>>>>>>>> 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.
