Hi Patrik, Thanks for pointing me at the actor-to-actor pull request - it seems like it would be very useful in "pipe to self" use-cases. It makes me wonder, though, if it wouldn't be possible to do something similar while "piping" to other actors.
In my experience (which admittedly, may not be representative), I have found that I use pipeTo(sender) much more than pipeTo(self). The main use-case where I see this is something like this: - "Client" actor sends a request to some "singleton" actor. - The "Singleton" actor routes the request to the appropriate destination. There are a few variations on these actors - sometimes they transform the requests/responses, sometimes they create child actors to route the request to. The important thing is they *don't change state/behavior* based on the response. - A single "request" flow can have several of these "singleton" actors, each considering the previous one the "client". In such cases, I much prefer transforming the future and piping back to the sender, as that keeps all the code in one place (in contrast, pipe-to-self breaks up the message flow and makes it hard to find the connection between the original request and its response). A possible solution to this could be to allow spawning adapters for *other* ActorRefs other than 'self'. Another thing regarding this API is that it hides the Future, making some patterns much more complicated (combining multiple asks, for example). This is probably fine, since you can still use the "external ask" API, but it's something to think about. (As an aside, the PR also drew my attention to the fact that I was leaking adapters, so that's something...) Tal On Sunday, January 28, 2018 at 5:49:53 PM UTC+2, Patrik Nordwall wrote: > > Hi Tal, > > Thanks a lot for taking it for a spin and sharing feedback. Comments > inline... > > sön 28 jan. 2018 kl. 14:10 skrev Tal Pressman <[email protected] > <javascript:>>: > >> I finally had the chance to use Akka Typed, and wanted to share my >> experience. So basically, I took a small demo project that was based on >> untyped actors, and implemented it using typed ones. (This is based on >> 2.4.8, but I think most of it is still relevant) >> >> To start off with the good things: >> * Typed actors completely eliminated bugs involving mixing up `ActorRef`s >> - passing wrong refs, mixing up order of parameters, sending responses to >> the wrong place. >> * The functional approach taken for typed actors (behaviors returning the >> next behavior) also eliminated bugs that revolved around "doing stuff from >> `Future` callbacks". >> * The thing I was probably worried about most - not having `sender` any >> more - turned out to be a non-issue. In fact, because now it has to be on >> the received message, it makes it immutable, thus helping with the >> `Future`-related bugs. >> >> Now for the "annoyances" (in no specific order): >> * Using the various factory methods to create behaviors means you don't >> have direct access to "protected" behavior methods, most notably the >> ActorContext. If you need it, you either use `Actor.immutable` and get a >> "new" context with each message, or you use Actor.deferred which is a bit >> more clunky (you need a function that returns a behavior, which is itself a >> function). >> > > That is “only” when you need the context when the actor is started. When > receiving messages the context is always there as a parameter. > > One perhaps related thing is that for a “more complicated” actor you > typically want to break it up in many methods/functions and you have to > pass a lot of parameters around to all. I’m not sure if that is only me > that see that as somewhat annoying. One way is to anyway create an > exclosing class and keeping such common parameters there. Especially in > Java I think that will often be used. (Or use mutable behavior). > > >> * This is more of a Scala type-inference issue, but having to specify the >> type when using `ask` is pretty annoying. What seems to work best for me is >> having utility methods >> on the "actor" that return `ActorRef[Response] => Message`, but it's a >> bit boilerplatey. >> > > There is a new actor-to-actor ask. Would be interesting to hear what you > think of that. > https://github.com/akka/akka/pull/24335 > > >> * Another issue related to asking is that there is no equivalent to >> untyped ask's Status.Failure. If the "request" can fail, this has to be >> modeled in the response (replying with a `Try`, or something equivalent), >> and means that now the caller has 3 cases to handle instead of 2. So now >> instead of ask-map-pipe in one line, it turns into >> ask-transform(3 cases)-foreach. >> > > Failure case is only for timeout, and in the actor-to-actor ask that is > represented as a specific message that you define. > > >> * No "easy" access to logging - there's already a PR waiting for this, so >> not really an issue. >> >> Overall, though, I have to say it's shaping up real nicely. I'm looking >> forward to see what happens to it next. >> > > Glad to hear that. Yes, we agree, it’s going to be awesome. > > /Patrik > >> >> >> Tal >> >> -- >> >>>>>>>>>> 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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > -- >>>>>>>>>> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
