[saryant]

The found a better solution so they switched to it?

That's bad?

As for the PartialFunction[Any, Unit] comment: well, yeah. That's the way actors work. They can be sent any message but may or may not respond. The company I work for has a very large Akka-based backend and that has honestly never been an issue for us. Moreover, it's necessary to facilitate hop-swapping (changing an actor's behavior dynamically during runtime). That is most certainly not a feature I would be willing to sacrifice. "context.become" is an incredibly powerful tool within Akka, especially in how it makes modeling a finite-state machine quite trivial in practice.

[lmm]

FWIW as a big scala fan I've given up on akka actors, until they manage to make typed ones that work (the current ones rely on an experimental reflection library that has threading bugs). The biggest advantage of Scala is type safety; if I wanted an unsafe language with actors I'd use Erlang.

[saryant]

Quite honestly, it's never a problem. In fact, I think it's a huge advantage. I simply would not be willing to give up the ability to change an actor's behavior dynamically.

We use the FSM helper [1] heavily in our backend at Conspire. For data-pipeline use cases, it's invaluable. Keeps our code concise, readable and testable. Even basic become/unbecome operations are big for us, I've written up one of their use cases on our blog [2].

[1] http://doc.akka.io/docs/akka/2.2.3/scala/fsm.html

[2] http://blog.goconspire.com/post/64901258135/akka-at-conspire...