4 ms·
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,
by 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 agoIsn’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 agoNone 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 agoWell 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". :)