[vbhavsar]

We make extensive use of Akka FSMs [1]. I find their implementation to be a lot more intuitive and less verbose than the Erlang implementation. Of course, that is in large part due to Scala's succinctness and fantastic DSL support.

FSMs make it so easy to read and debug code. It helps that Akka uses an actor system (based on Erlang's actor system), which simplifies dealing with concurrency.

> However, if the dog is sitting and you pet it, we have no idea what might happen. In the Erlang world, the dog could crash (and eventually be restarted by its supervisor).

Akka FSMs have a whenUnhandled state which can handle any event that your FSMs don't explicitly handle. Also, not handling an event doesn't cause the actor to crash. The event ends up being dead lettered.

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

[lostcolony]

So, just to point out, the quote you're referencing is about the diagram, not the code. That is, the expected use case of the dog is undefined in that case; what the code does is thus undefined, and up to the implementor. It COULD crash. Or it could be handled. Or the message could just sit in the mailbox unanswered (messages that match no case clauses sit in the mailbox because the code may at a later date be able to handle such a message; see below). It's up to you.

We even see an example of that in the code. All those pattern matches with _ in them are the 'default' handling, the "it matched nothing else so match here and handle it". If it matched part of the receive clause, but that was not coded to handle that kind of message (your guard was insufficient), then it could crash (eg: receive {event, Pid} -> Pid ! blah, but you send the message {event, "stuff"}, would crash, since you can't send an event to a string).

That's actually a pattern I've noticed when it comes to Erlang vs Scala/Akka. A lot of the things that have special syntax in Scala/Akka, don't in Erlang, because they just flow naturally out of the language primitives. Another example is Akka's "become". In Erlang, you just call another function, that has a different receive block. And that's also why messages just sit in the mailbox if they match nothing; because the actor may enter a different receive block at a later time, that -can- respond to that kind of message.

[rdtsc]

> Akka FSMs have a whenUnhandled state which can handle any event that your FSMs don't explicitly handle.

Erlang's gen_fsm has that too:

http://erlang.org/doc/man/gen_fsm.html#Module:handle_event-3

However that is a dangerous anti-pattern usually. More often than not, I want the actor to crash and have a proper trace and notification of it most of the time than have it go to some unspecified state and hang around forever in that broken state.