You are correct.

That's something I've been a bit worried about with people coming to Elixir thinking it's basically a faster/robust Ruby: are they absorbing the full Erlang Weltanschauung?

(I had to look it up)

Welt·an·schau·ung ˈveltˌänˌSHouəNG

a particular philosophy or view of life; the worldview of an individual or group.

--

Personally I came for the faster/robust Ruby first and then over time discovered (and am still discovering) the other powerful pieces. I think that's ok.

Absolutely that's ok. Everything's a journey.

(I tend to get lazy about learning, so perhaps I doth project too much.)

Was Elixir designed with Ruby in mind?

It was designed by José Valim, a Rails core team member.

I think you are right. Good point.

I am also in the process of learning, so your reply is a valuable for me.

Thanks

But does reliability in Elixir/Erlang come only from processes or is it result of the "teamwork" of several features of the platform itself?

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.

Elixir newbie here.

My understanding if that Agent[1] was designed specifically to keep state. But then again, an Agent is a GenServer is a process, so I guess the post just served as a introduction to the concept of a Elixir process.

[1] https://hexdocs.pm/elixir/Agent.html

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.