4 ms·

I think you're very confused. Systems like Elixir are powerful because with care they make it easy to design reliable systems where state is marked off in hand

I think you're very confused. Systems like Elixir are powerful because with care they make it easy to design reliable systems where state is marked off in handleable places where state - the source of the trickiest errors - is contained and process faults are segmented and do not cascade. You talk about supervision trees as if they are an avoidable source of complexity. Well if you're going to design a stateless request system you'll still need systems to manage dns lookups, elastic load balancing, and what is going to happen when a backhoe cuts the fibre to the data center where your code resides. That complexity will exist no matter what, it's just that when you use the beam you do it mostly in one language instead of having to wrangle reams of YAML with a tee ruler. Have you ever deployed anything in Elixir? Your commentary makes it seem like you only have a superficial and incorrect understanding of the relationship Elixir has with statefulness and statelessness. Hell, your primary complaint, is addressed right in the Elixir Documentation: "When not to use a GenServer" https://hexdocs.pm/elixir/GenServer.html#module-when-not-to-use-a-genserver https://hexdocs.pm/elixir/GenServer.html#module-when-not-to-... > If you don't need a process, then you don't need a process. Use processes only to model runtime properties, such as mutable state, concurrency and failures, never for code organization. I strongly recommend you watch "boundaries" by Gary Bernhardt. This talk (which precedes elixir) exemplifies the programming philosophy that elixir has attained, though I don't know if that evolved organically or not. The point is, you have to accept that some parts of the universe are going to be stateful. You model those parts carefully, and then encapsulate it in a stateless core which precisely does only data transformations.

abernard1 7y ago
I've used Akka for a decade (basically as soon as it came out) and am quite familiar with systems designed by the Erlang/Elixir community. While actors definitely are a powerful mechanism for reasoning about stateful systems, most business systems are better off without having to design their own _technical_ distributed systems or in-app persistent state model. There is a reason that dedicated systems like Zookeeper, Redis, squid, relational databases, etc. exist, and that's because those things are insanely hard. Those systems also do not need to know about your business problem. The actor model, and Elixir w/ OTP subtly encourage coupling of technical, distributed systems problems in the same application scope as the business problem. This is where that thorny state comes into play, and I believe it's a fundamentally wrong instinct. (It is also an instinct that is relatively vocal within the Elixir community: "throw OTP at it!", "once you need to scale, you can just add more machines to your problem!", etc.). I have a rule on design reviews. I ask the team "is this system a technical system or a business system?" If they say "both", I ask them to make it into two systems, one technical and one business. Most likely, a "simple" technical system that does what they want already exists, and we can use it. While OTP and actors are good at designing interfaces or protocols for distributed systems, writing bespoke error handling for your business code with actors is going to be buggy and wrong. Make the business code pawn off state coordination or storage problems to systems with known, provable properties and a remote interface. (That interface will also be usable by other languages, and not tied to the Erlang VM).
- dnautics 7y ago
  > The actor model, and Elixir w/ OTP subtly encourage coupling of technical, distributed systems problems in the same application scope as the business problem. This is where that thorny state comes into play, and I believe it's a fundamentally wrong instinct. I disagree that Elixir encourages coupling those systems. While erlang comes with no such help, in Elixir, you should be decoupling your distribution problems from your business logic by putting them into different applications within the same umbrella. Sure, there will be a coupling in the sense that they will live in the same VM, but that is abstractly similar to "our microservices all live in {AWS/GCP/K8s}", especially given the level of process isolation that the BEAM affords you. But for all intents and purposes (program design, testing, heck you can even pick and choose components for deployment) they are decoupleable.
  - abernard1 7y ago
    > Sure, there will be a coupling in the sense that they will live in the same VM, but that is abstractly similar to "our microservices all live in {AWS/GCP/K8s}", especially given the level of process isolation that the BEAM affords you. I disagree that these are conceptually similar. If all my microservices are in a certain cloud, it does not imply that any important state is maintained in those services and not a database. It also does not require me to have my services in Erlang or whatever the actor model is written in. Actor supervision systems (in whatever language) are essentially narcisstic: they have to be in control over the state management lifecycle. Actors fundamentally are of the philosophy where some state lives in the application, and it's mutated by these incoming messages. This is totally different from systems that scale, where any application "state" is just transient from a request or message in order to facilitate a mutation in a dedicated store outside of the app. There's many reliability benefits to that: language independence, being able to know the operational characteristics of state management don't change out from under you when you release a new version of code, ability to query state operationally without having to run map-reduce across code in your cluster (how fun would it be to write "get me the relevant state of my system" for a custom-written actor hierarchy instead of SQL?).
    - 7y ago

abernard1 7y ago

I've used Akka for a decade (basically as soon as it came out) and am quite familiar with systems designed by the Erlang/Elixir community. While actors definitely are a powerful mechanism for reasoning about stateful systems, most business systems are better off without having to design their own _technical_ distributed systems or in-app persistent state model. There is a reason that dedicated systems like Zookeeper, Redis, squid, relational databases, etc. exist, and that's because those things are insanely hard. Those systems also do not need to know about your business problem. The actor model, and Elixir w/ OTP subtly encourage coupling of technical, distributed systems problems in the same application scope as the business problem. This is where that thorny state comes into play, and I believe it's a fundamentally wrong instinct. (It is also an instinct that is relatively vocal within the Elixir community: "throw OTP at it!", "once you need to scale, you can just add more machines to your problem!", etc.). I have a rule on design reviews. I ask the team "is this system a technical system or a business system?" If they say "both", I ask them to make it into two systems, one technical and one business. Most likely, a "simple" technical system that does what they want already exists, and we can use it. While OTP and actors are good at designing interfaces or protocols for distributed systems, writing bespoke error handling for your business code with actors is going to be buggy and wrong. Make the business code pawn off state coordination or storage problems to systems with known, provable properties and a remote interface. (That interface will also be usable by other languages, and not tied to the Erlang VM).

dnautics 7y ago
> The actor model, and Elixir w/ OTP subtly encourage coupling of technical, distributed systems problems in the same application scope as the business problem. This is where that thorny state comes into play, and I believe it's a fundamentally wrong instinct. I disagree that Elixir encourages coupling those systems. While erlang comes with no such help, in Elixir, you should be decoupling your distribution problems from your business logic by putting them into different applications within the same umbrella. Sure, there will be a coupling in the sense that they will live in the same VM, but that is abstractly similar to "our microservices all live in {AWS/GCP/K8s}", especially given the level of process isolation that the BEAM affords you. But for all intents and purposes (program design, testing, heck you can even pick and choose components for deployment) they are decoupleable.
- abernard1 7y ago
  > Sure, there will be a coupling in the sense that they will live in the same VM, but that is abstractly similar to "our microservices all live in {AWS/GCP/K8s}", especially given the level of process isolation that the BEAM affords you. I disagree that these are conceptually similar. If all my microservices are in a certain cloud, it does not imply that any important state is maintained in those services and not a database. It also does not require me to have my services in Erlang or whatever the actor model is written in. Actor supervision systems (in whatever language) are essentially narcisstic: they have to be in control over the state management lifecycle. Actors fundamentally are of the philosophy where some state lives in the application, and it's mutated by these incoming messages. This is totally different from systems that scale, where any application "state" is just transient from a request or message in order to facilitate a mutation in a dedicated store outside of the app. There's many reliability benefits to that: language independence, being able to know the operational characteristics of state management don't change out from under you when you release a new version of code, ability to query state operationally without having to run map-reduce across code in your cluster (how fun would it be to write "get me the relevant state of my system" for a custom-written actor hierarchy instead of SQL?).
  - 7y ago