To be clear. I am not forcing her to use that app to much. We do that as much as she likes. And I can see she has fun seeing "a cat moving along the street".
I have started the series of articles about learning Phoenix and the Prater is the example application I'm using to cover different topics in my learning way.
Prater is the chat application which should help me to cover many different topics about Phoenix and Elixir.
These write-ups look really useful. There are many out there but they either tend to be too verbose, or cover too small an area. You cover a bit more end-to-end but in a concise and complete way.
Also, it's great to pick off-the-beaten-path topics: the Phoenix command-line one is one I recently actually had to sort out from bits I found here and there.
Other topics I'd be interested in (if you need some suggestions):
- more advanced Ecto usage such has ways to work around some limitations (e.g. fragment() or execute(SQL) for migrations)
- the whole GenServer thing. How these Erlang/Elixir tasks run in a logical machine seamlessly over the network with high uptimes.
Yes. That is correct. I am going to cover Agents, Tasks and OTP in the following articles.
I thought the article would be too big if I cover all three topics at once.
You won't have Erlang-style reliability (predictable recovery after localized
errors) without links, monitors, and supervisors, which themselves are built
with links and monitors.
Plus immutability, plus message passing paradigm (and the associated distribution).
The immutability prevents entire classes of bugs, and helps enforce predictability on the part of your code. It also is assumed at least in part when it comes to message passing (else, what happens if you change a referenced binary after passing it in a message? Does the message change too, or remain static? Either way, complexity)
The message passing paradigm for interprocess communication ensures that the developer is forced to ask "What happens if this isn't received", i.e., if the process is down or missing or etc. Any sort of 'return', via a message sent back, could not happen; this is akin to a called function throwing, which again, requires the developer to ask 'what happens if we never get this response back'? The answer is never to wait indefinitely, it's to...what? Other languages make it very easy to ignore possible exceptions; in Erlang, not only are they likely handled (if you have your supervisor structure in place), but you're forced to decide how such a thing in another process affects the current process (if at all).
Because of the message passing paradigm, the distribution story is simplified; it's largely transparent as to whether the process you're sending a message to is local, or remote. This allows you to build in redundancy across nodes without many of the complexities (and thus, room for errors) that other languages give you, nor the lying abstractions many languages give you (such as RMI).
And having the distribution Erlang does helps with the reliability side of things, as it makes it comparatively straightforward (still complex, but far less so than most other languages) to get solid handling in the event of machine failure.
