> A reply() construct is not present in Erlang, where you are forced to include the sender each time you want to be able to receive replies. This is not a bad thing however: Scala messages always carry the identity of the sender with them to enable this functionality. This causes a tiny bit of extra overhead, which might be too much in performance critical applications.
An other nice result of Erlang's way (which I'm not sure can be replicated in reply-based Scala interactions) is that the message can be bounced around privately between processes until the final reply is sent (just forward a possibly transformed message with the same contained PID to the next guy in the chain)
While this could be done by having the initial receiver act as a middleman, it also means either that middleman has to be blocked until it can craft the final reply or it has to keep a bunch of state around (for each message it received) in order to correctly act on reply information. This lowers its throughput (and may even deadlock it for the former case) and increases its memory requirements. Erlang's way also makes it much easier to spin new processes to handle each message.
The article doesn't use the OTP libraries in Erlang unfortunately. This means that you have a view of low-level Erlang message passing, but most - proper - Erlang programs will process messaging at a much higher abstraction.
The most important omission in the example is to monitor processes. If an error occurs in another process while it is processing for a client should have the client knowing about that problem. Otherwise you are facing either a dead-lock situation or a timeout condition which you have to wait until triggers.
In other words: Real Erlang programming is not like this.
An other nice result of Erlang's way (which I'm not sure can be replicated in reply-based Scala interactions) is that the message can be bounced around privately between processes until the final reply is sent (just forward a possibly transformed message with the same contained PID to the next guy in the chain)
While this could be done by having the initial receiver act as a middleman, it also means either that middleman has to be blocked until it can craft the final reply or it has to keep a bunch of state around (for each message it received) in order to correctly act on reply information. This lowers its throughput (and may even deadlock it for the former case) and increases its memory requirements. Erlang's way also makes it much easier to spin new processes to handle each message.