Hacker News new | ask | show | jobs
by profdemarco 4567 days ago
They were (or are) being deprecated because they were broken beyond repair. That's pretty damning considering that all of the things I mentioned have been done properly in plenty of other languages. They aren't treading new ground here.

> Akka actors (which are awesome, BTW).

PartialFunction[Any, Unit]. Ridiculous.
1 comments
saryant 4567 days ago
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.

link
lmm 4565 days ago
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.
link
saryant 4565 days ago
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...

link