4 ms·

I suppose this is good basic information for people new to Erlang/Elixir, but I don't feel like it does a good job of explaining the significance of the fact th

I suppose this is good basic information for people new to Erlang/Elixir, but I don't feel like it does a good job of explaining the significance of the fact that state is stored in a process, compared to other frameworks which would store the state in a dictionary and retrieve it for each event/request as its dispatched in an event loop or whatever. I'd think the dictionary approach is functionally equivalent in most respects, and could even imitate how crashes are handled in Elixir. The framework has to implement more code to do this (e.g. messages between processes might be something some frameworks don't bother to implement because its such a hassle, while its almost free in Elixir), but that doesn't matter at all to users of the framework if the features are there.

weatherlight 3y ago
In essence, the dictionary approach you're referencing isn't entirely dissimilar to Elixir's process-based state management, and you're absolutely correct that, at a fundamental level, they both accomplish a similar task: preserving state across requests. However, I'd argue that the key difference lies in the granularity of control and the inherent characteristics of the Erlang/Elixir process model, which is designed to excel in concurrent, real-time, and distributed systems. For instance, in Elixir, every LiveView session is an isolated process that runs concurrently. This is native to the BEAM (Erlang's virtual machine), not an add-on. It's this built-in process model that allows LiveView to handle many users simultaneously, manage state efficiently, and push real-time updates, all while maintaining high performance. Fault isolation, too, is a baked-in benefit of this process model. A crash in one process doesn't affect others. While it's certainly feasible to engineer fault isolation in a different paradigm, it's a baseline guarantee in Elixir, reducing a considerable amount of potential complexity from the get-go. Elixir's supervision trees further provide a robust way of handling failures, automatically restarting processes when they crash. Implementing a similar mechanism outside of Elixir can be quite intricate and might not offer the same level of reliability. Additionally, Elixir processes facilitate straightforward and efficient inter-process communication, making it easier to build distributed and concurrent systems. Other frameworks could implement similar features, but it might not be as effortless or as integral a part of the programming model as it is in Elixir. So, while the dictionary approach can mimic some aspects of Elixir's processes, Elixir's model provides a more complete, integrated solution for building highly concurrent, real-time systems. The fact that many of these features are "almost free" in Elixir does matter, as it can reduce the complexity of application code, improve robustness, and increase developer productivity.
- throwawaymaths 3y ago
  > Fault isolation, too, is a baked-in benefit of this process model I wouldn't call it baked in, it's the entire purpose of the process model. The other benefits of the process model are secondary.
  - manmal 3y ago
    Isn’t it another quite important trait of this that one can manage millions of „processes“ on one machine which is outright impossible with most other systems? It puts a one machine setup for mid sized apps into the range of the possible.
- jeremyjh 3y ago
  None of this is new information to me or contradicts anything in my post. Yes, Elixir has a lot of features that are nice and save framework developers time. That's why I've been using Elixir for the last 10 years. But most of us reading this article do not develop frameworks, we develop applications. And when we choose a framework to use for that, we look at the features it provides, not the features it leverages from lower-level frameworks.
  - HappMacDonald 3y ago
    Well in that case this boils down to: "LiveView does this for you. In fact it does this because the underlying language does this for you. Most other frameworks in other languages do not do this for you. You might be able to roll your own but it would be a huge headache to do". :)
OkayPhysicist 3y ago
The message passing is, IMO, the biggest win you get from the process model. In the process model, you have the LiveView process, which sits there, listening for messages, which it can receive both from the browser client, or from independent going-ons in the backend, quite symmetrically. To the programmer, it looks just like any other process that you'd be used to using everywhere in Elixir, which provides useful interop with things like Task.async, which sends a message back to it's linked process on completion, or other libraries that are completely unaware of LiveView. You could simulate the same thing with a dictionary lookup scheme, but A) it would be far more complex, because of the lack of native message passing support, and B) the you'd miss out on the symmetries and interop, because the rest of your program wouldn't be using message passing.

weatherlight 3y ago

In essence, the dictionary approach you're referencing isn't entirely dissimilar to Elixir's process-based state management, and you're absolutely correct that, at a fundamental level, they both accomplish a similar task: preserving state across requests. However, I'd argue that the key difference lies in the granularity of control and the inherent characteristics of the Erlang/Elixir process model, which is designed to excel in concurrent, real-time, and distributed systems. For instance, in Elixir, every LiveView session is an isolated process that runs concurrently. This is native to the BEAM (Erlang's virtual machine), not an add-on. It's this built-in process model that allows LiveView to handle many users simultaneously, manage state efficiently, and push real-time updates, all while maintaining high performance. Fault isolation, too, is a baked-in benefit of this process model. A crash in one process doesn't affect others. While it's certainly feasible to engineer fault isolation in a different paradigm, it's a baseline guarantee in Elixir, reducing a considerable amount of potential complexity from the get-go. Elixir's supervision trees further provide a robust way of handling failures, automatically restarting processes when they crash. Implementing a similar mechanism outside of Elixir can be quite intricate and might not offer the same level of reliability. Additionally, Elixir processes facilitate straightforward and efficient inter-process communication, making it easier to build distributed and concurrent systems. Other frameworks could implement similar features, but it might not be as effortless or as integral a part of the programming model as it is in Elixir. So, while the dictionary approach can mimic some aspects of Elixir's processes, Elixir's model provides a more complete, integrated solution for building highly concurrent, real-time systems. The fact that many of these features are "almost free" in Elixir does matter, as it can reduce the complexity of application code, improve robustness, and increase developer productivity.

throwawaymaths 3y ago
> Fault isolation, too, is a baked-in benefit of this process model I wouldn't call it baked in, it's the entire purpose of the process model. The other benefits of the process model are secondary.
- manmal 3y ago
  Isn’t it another quite important trait of this that one can manage millions of „processes“ on one machine which is outright impossible with most other systems? It puts a one machine setup for mid sized apps into the range of the possible.
jeremyjh 3y ago
None of this is new information to me or contradicts anything in my post. Yes, Elixir has a lot of features that are nice and save framework developers time. That's why I've been using Elixir for the last 10 years. But most of us reading this article do not develop frameworks, we develop applications. And when we choose a framework to use for that, we look at the features it provides, not the features it leverages from lower-level frameworks.
- HappMacDonald 3y ago
  Well in that case this boils down to: "LiveView does this for you. In fact it does this because the underlying language does this for you. Most other frameworks in other languages do not do this for you. You might be able to roll your own but it would be a huge headache to do". :)

OkayPhysicist 3y ago

The message passing is, IMO, the biggest win you get from the process model. In the process model, you have the LiveView process, which sits there, listening for messages, which it can receive both from the browser client, or from independent going-ons in the backend, quite symmetrically. To the programmer, it looks just like any other process that you'd be used to using everywhere in Elixir, which provides useful interop with things like Task.async, which sends a message back to it's linked process on completion, or other libraries that are completely unaware of LiveView. You could simulate the same thing with a dictionary lookup scheme, but A) it would be far more complex, because of the lack of native message passing support, and B) the you'd miss out on the symmetries and interop, because the rest of your program wouldn't be using message passing.