8 ms·

While it's always dangerous to criticize a computer legend, I would add one more thing that I believe Alan Kay "got wrong about objects": objects are extremely

While it's always dangerous to criticize a computer legend, I would add one more thing that I believe Alan Kay "got wrong about objects": objects are extremely bad at representing most types of problems in business software. I mean this in regards to the "true" message-passing type of actor objects, and not OO as it came to be post-C++ and Java. The reason being is that actors 1) fundamentally involve themselves with state and time, and 2) connect subject and recipient together directly. In relation to 1), most business problems involve _data_ processing, and the thing about data is it is immutable. It's essentially a solid state type of activity, and bears no resemblance to the organic, messy world of biology where things are changing. For problems like these, you really want to avoid state in your program, and persist state after data transformation in an actual database. Concepts like stateful actor supervision hierarchies, and what to do with clearing mailbox state when something goes wrong are fundamentally complex. Those concepts are also broadly unnecessary (and arguably harmful) for most request/response or async pub-sub type software. I can't count the amount of time I've wasted redoing systems on an actor model to be a simple "stateless" request model. On all of those occasions, the model that didn't persist state in-app was more reliable, easier to understand, less code, and more maintainable. With respect to 2), actors basically violate all concepts of dependency injection. Actors need to know exactly where they're going (or you can add a proxy, and now your state graph is even more complicated), and even with message passing, program flow is dependent upon _time_ and the order in which a program is run. This is a large step backwards in my opinion. I feel that languages like Elixir that pride themselves on stateless, immutable functions, have a deep contradiction internally embracing the actor model, because it is none of those things. Sadly, I also predict that this generation of Elixir programmers will learn the lessons of the Waldo paper the hard way: you can't just throw an actor model over the network and have it work great. (I think it's especially interesting that most of the success stories around modern day actor systems involve problems that can withstand data loss: telephones, IOT, content, media streaming, games, etc.)

paulddraper 7y ago
> most business problems involve _data_ processing To quote two other computer legends, Fred Brooks and Linus Torvalds are right: data not behavior is the more crucial part of programming. Actors focus on the behavior, whereas the data is the part that is really important. What `git log` does isn't all that important relative to how the git object model is structured, as the latter dictates the former. > I can't count the amount of time I've wasted redoing systems on an actor model to be a simple "stateless" request model. So much this. So often people forget that "it's just code". It can run on a toaster, or a mainframe, or a VPS, or a Docker container, or a Lambda function. The lion's share of code should be structured as input => output in the most straightforward way possible.
- Fice 7y ago
  «What if "data" is a really bad idea?» — Alan Kay, https://news.ycombinator.com/item?id=11945722 https://news.ycombinator.com/item?id=11945722
  - paulddraper 7y ago
    Ah, it would seem that is in fact an underlying point of disagreement.
- ProfHewitt 7y ago
  Even Git has a complicated behavior that changes. For example, each new commit changes the behavior of Git.
pacala 7y ago
Thanks for clearly articulating why the actor model is poorly suited to model data and control flow. In practice, the complexity of the control flow also amplifies the challenge of managing schema and control flow evolution. Particularly challenging when mixed with persisted messages, for example when using https://doc.akka.io/docs/akka/current/persistence.html https://doc.akka.io/docs/akka/current/persistence.html
dnautics 7y ago
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).
nnq 7y ago
You're actually advocating for an "actor model" yourself, you know :) The actor model of "actors as services" and "messages as API calls" that has practically won in the real world. It also has the advantage of not being tied to one particular VM and it's polyglot by nature. It also isn't something that can be "scaled down" to language level constructs, and maybe that's for the best. Cells aren't made up of organs or of other smaller cells (mythocondria are quite exceptions, and the pattern goes only one level deep). I think the deeper truth here is that truly good architectures are emergent/evolved, not designed/architected... only problem is that they tend to emerge/evolve on time scales longer than the lifetime of most businesses, so you can't take the approach of "let's evolve the right architecture" and actually be able to ship anything on time. Don't know a "solution" for this other than staying humble and mentally flexible. Quite zen-ish ironical to think that the deepest wisdom we got so far in distributed may be the "PHP + MySQL" model of statelessness, short live isolated processes and business-valuable state kept in specialized storage systems :) The language you use for message processing is largely irrelevant as long as you keep the processing of messages isolate and transient (eg. throw away everything, including leaked/overflowed memory, after processing a message and replying - most systems besides PHP still fail at this!), the data store is also irrelevant as long as it support some basic transactional guarantees and you can easily back it up and import/export data from it to other systems better suited for other tasks.
- paulddraper 7y ago
  > the deepest wisdom we got so far in distributed may be the "PHP + MySQL" model of statelessness, short live isolated processes and business-valuable state kept in specialized storage systems PHP + MySQL was necessitated for a class of computer programs that process durable, broadly distributed information. And the "deepest wisdom" is to ignore the distributed nature as much as possible. Yes there is a primitive actor-like model but that is because we more or less have to meet business requirements. If it were possible to scrap the distributed nature of it, we would.
ProfHewitt 7y ago
Business software must deal with change! Even something as simple as a financial account changes behavior because the balance in the account changes. Of course, many business Actors never change their behavior. For example, a quarterly report to the SEC never changes although additional reports to the SEC may correct information in previous reports. Of course, you know that Factorial is an Actor that never changes behavior :-) Also, the (infinite) list of prime numbers is an Actor that never changes behavior.

paulddraper 7y ago

> most business problems involve _data_ processing To quote two other computer legends, Fred Brooks and Linus Torvalds are right: data not behavior is the more crucial part of programming. Actors focus on the behavior, whereas the data is the part that is really important. What `git log` does isn't all that important relative to how the git object model is structured, as the latter dictates the former. > I can't count the amount of time I've wasted redoing systems on an actor model to be a simple "stateless" request model. So much this. So often people forget that "it's just code". It can run on a toaster, or a mainframe, or a VPS, or a Docker container, or a Lambda function. The lion's share of code should be structured as input => output in the most straightforward way possible.

Fice 7y ago
«What if "data" is a really bad idea?» — Alan Kay, https://news.ycombinator.com/item?id=11945722 https://news.ycombinator.com/item?id=11945722
- paulddraper 7y ago
  Ah, it would seem that is in fact an underlying point of disagreement.
ProfHewitt 7y ago
Even Git has a complicated behavior that changes. For example, each new commit changes the behavior of Git.

pacala 7y ago

Thanks for clearly articulating why the actor model is poorly suited to model data and control flow. In practice, the complexity of the control flow also amplifies the challenge of managing schema and control flow evolution. Particularly challenging when mixed with persisted messages, for example when using https://doc.akka.io/docs/akka/current/persistence.html https://doc.akka.io/docs/akka/current/persistence.html

dnautics 7y ago

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).

nnq 7y ago

You're actually advocating for an "actor model" yourself, you know :) The actor model of "actors as services" and "messages as API calls" that has practically won in the real world. It also has the advantage of not being tied to one particular VM and it's polyglot by nature. It also isn't something that can be "scaled down" to language level constructs, and maybe that's for the best. Cells aren't made up of organs or of other smaller cells (mythocondria are quite exceptions, and the pattern goes only one level deep). I think the deeper truth here is that truly good architectures are emergent/evolved, not designed/architected... only problem is that they tend to emerge/evolve on time scales longer than the lifetime of most businesses, so you can't take the approach of "let's evolve the right architecture" and actually be able to ship anything on time. Don't know a "solution" for this other than staying humble and mentally flexible. Quite zen-ish ironical to think that the deepest wisdom we got so far in distributed may be the "PHP + MySQL" model of statelessness, short live isolated processes and business-valuable state kept in specialized storage systems :) The language you use for message processing is largely irrelevant as long as you keep the processing of messages isolate and transient (eg. throw away everything, including leaked/overflowed memory, after processing a message and replying - most systems besides PHP still fail at this!), the data store is also irrelevant as long as it support some basic transactional guarantees and you can easily back it up and import/export data from it to other systems better suited for other tasks.

paulddraper 7y ago
> the deepest wisdom we got so far in distributed may be the "PHP + MySQL" model of statelessness, short live isolated processes and business-valuable state kept in specialized storage systems PHP + MySQL was necessitated for a class of computer programs that process durable, broadly distributed information. And the "deepest wisdom" is to ignore the distributed nature as much as possible. Yes there is a primitive actor-like model but that is because we more or less have to meet business requirements. If it were possible to scrap the distributed nature of it, we would.

ProfHewitt 7y ago

Business software must deal with change! Even something as simple as a financial account changes behavior because the balance in the account changes. Of course, many business Actors never change their behavior. For example, a quarterly report to the SEC never changes although additional reports to the SEC may correct information in previous reports. Of course, you know that Factorial is an Actor that never changes behavior :-) Also, the (infinite) list of prime numbers is an Actor that never changes behavior.