5 ms·

I'm in the process of learning Elixir and the observation I'm about to make may be completely off-base. With that said... Seems like the section on "When to us

I'm in the process of learning Elixir and the observation I'm about to make may be completely off-base. With that said... Seems like the section on "When to use processes" is selling processes short a bit. Certain kinds of state management would seem to call for processes to either manage or even hold state... but processes (as I understand them) are also key in designing for reliability. So I would think I may well want to organize my code relative to processes as I'm also figuring out the supervision trees and various failure scenarios. And yes, concurrency issues as well. If I'm wrong on this, I'd be happy to be set straight. Anyway, yes, the section I speak of does get to some of the other parts of what I mention, but the emphasis on state management seems to distort and unbalance the view of what you might want as a process. [edited a touch for clarity]

macintux 9y ago
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?
- udfalkso 9y ago
  (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.
  - macintux 9y ago
    Absolutely that's ok. Everything's a journey. (I tend to get lazy about learning, so perhaps I doth project too much.)
- debacle 9y ago
  Was Elixir designed with Ruby in mind?
  - macintux 9y ago
    It was designed by José Valim, a Rails core team member.
ck3g 9y ago
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?
- dozzie 9y ago
  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.
  - lostcolony 9y ago
    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.
fasteo 9y ago
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 https://hexdocs.pm/elixir/Agent.html
- ck3g 9y ago
  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.

macintux 9y ago

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?

udfalkso 9y ago
(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.
- macintux 9y ago
  Absolutely that's ok. Everything's a journey. (I tend to get lazy about learning, so perhaps I doth project too much.)
debacle 9y ago
Was Elixir designed with Ruby in mind?
- macintux 9y ago
  It was designed by José Valim, a Rails core team member.

ck3g 9y ago

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?

dozzie 9y ago
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.
- lostcolony 9y ago
  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.

fasteo 9y ago

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 https://hexdocs.pm/elixir/Agent.html

ck3g 9y ago
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.