Is Phoenix 'Reactive' like the Play framework?

[rvirding]

@peerreynders

Message passing is supposed be “asynchronous” but that doesn’t mean it’s impossible implement an inefficient “synchronous” solution. For example, one of Rich Hickey’s criticisms of the Actor model is:

It is a much more complex programming model, requiring 2-message conversations for the simplest data reads, and forcing the use of blocking message receives, which introduce the potential for deadlock.

The material that I’ve being going through suggests to me: “handle_cast when possible, handle_call when needed”, i.e. organize the design like a bucket brigade rather than allocating one person to each bucket - so that we minimize emulating function calls with “2-message conversations” (and then processes block simply because they have nothing to do).

I personally think that Rich Hickey got it completely back-to-front wrong here. Using calls you are always synchronous and will always block so the chance of deadlock is enormous. Using actors/erlang processes means that the base for communication of all kinds is asynchronous, you have to be explicit when you want you synchronous. Granted that this requires rethinking on how you structure your system but when you get it right you actually have to work at making the system block.

It is however a real rethink and in many cases you have to seriously change how you do things. For example it is a lot less of “what is the answer” and much more of “send me your answer” and this will change your system. Think email: you mail a request then go out and do other things and when the reply has been sent to you and you have the time to read it then you will process it.

I will try to find some very simple erlang code which illustrates this way of thinking, it is a simple telephony example.

I will not get into the discussion of reactive and phoenix as I don’t know enough phoenix to say something sensible in it.