How does that work? I've never seen an example, and I don't see how you could do it cleanly without growing the stack, given the JVM's constraints. Also to add

How does that work? I've never seen an example, and I don't see how you could do it cleanly without growing the stack, given the JVM's constraints. Also to add onto yetihehe's comment, it's -really freaking easy- to debug such a server as Joe illustrates, or anything else that behaves in such a way (changing behavior by calling another function, to eventually wind up in a different receive statement), in Erlang. It's effectively an FSM determining what kind of messages you handle, the stack traces are clean (TCO means any time you get an exception, it's only in the current 'state'); the only complexities are the fact you're building an FSM, i.e., making sure your transitions are right, and what to do about out of order messages (i.e., a message that doesn't match the current state). There's nothing specific about the Erlang code that makes it harder to debug than the Akka code; in fact, just the fact it's pure Erlang makes it easier; your stack traces are going to be just your own code, no libraries muddying them up. As for demarcation...it's not really any different. That is, Scala's def func:Receive = { //cases } def receive = { case "foo" => become(func) } is equivalent to Erlang's func() -> receive %cases end. receive "foo" -> func() end. But you'll note that in Joe's example he even uses the atom 'become' to indicate the transition is happening, i.e., receive {become, F} => F() end). It's totally equivalent. I'm not saying Scala is less clean, or whathaveyou, just that Akka felt they had to create a new keyword, for some reason, rather than leave it up to the user to implement. Exactly why, or whether it's equivalent to calling a function, I don't know (having never seen an example of the latter, nor commentary on its characteristics re: call stack); my point was simply that it's a natural extension of the language fundamentals in Erlang, but Akka felt the need to create a new keyword just for it, and that people often miss that needed complexity can arise out of a solid set of fundamentals.