[coderdd]

Actor frameworks with message passing, just like direct mutation, don't compose.

On Haskell, yes, you can just work off a thread and write shared buffers. But you are better off using STM or Async (these are a bit like futures), which compose, and you can write pipelines out of them.

[pdimitar]

Everything that you pointed out can be achieved in Elixir, quite easily too. If I understood you correctly.

Not sure what you mean by "actor frameworks don't compose"?

[dnautics]

Actor frameworks don't compose, because actors are an atomic compute unit. You can't really take a horse actor and a bird actor and turn them into a pegasus actor. There are non-trivial interactions between message handling logic that would prevent such a thing with some fairly trivial-to-generate breaking cases.

Maybe composition for compositions' sake isn't that important?

[pdimitar]

> Maybe composition for compositions' sake isn't that important?

Definitely. I was about to ask "but when did you actually need to compose actors and how does that even make sense?" -- and while I am sure there are people who would find a scenario I feel that would still be tarrying on minutiae.

Obviously the actor model is not a panacea. But for my commercial work Elixir -- and thus Erlang's OTP -- has been a true blessing. There aren't many commercial scenarios where OTP is a very poor fit. They do exist but I'd dare saying they are no more than 10-15% of everything you can stumble upon out there.

[dnautics]

Yep I love Elixir too. Just, you know, I try to only sip the kool-aid.

[pdimitar]

Well, I am just now arguing with people in another thread that nobody claims that Elixir is an end-all be-all.

It's quite sad how fiercely the average HN audience is attacking people who are trying to show an alternative way of doing things.

[eru]

You can write great and useful software in non-composable languages. People write good stuff in C or Go.

But if you have the choice, composability always seems much nicer to me and stops me wanting to tear my hair out.

[pdimitar]

This is definitely true, I am just not sure how well it applies to actors. For all data-modelling scenarios and OOP/FP ways of doing polymorphism, composability is a life-saver though.

[eru]

It's a good question. Let me meditate on actors and STM. Perhaps there's a way to get something like vectors that's composable.

[dnautics]

The point of the actor model, at least in OTP, is not to have the actor model as a unit of computation (as was imagined by Hewitt, et, al) but as a failure domain. Erlang was not designed to be an actor system, it was designed to be a robust system and they later discovered that what they had built was more or less the actor model (if an impure version) and it was easy to communicate the architecture's computational capabilities and mental model as actors. Actually I think if anything it's led to a fair share of misunderstandings, and truly misses the important and unique aspects of Erlang processes.

In the sense of being failure domains, OTP "actors", or processes, ARE composable. With very little boilerplate, that is built in as primitive BIFs in the standard library, I can bundle failure domains together and orchestrate them using links, monitors, and supervision strategies, with the ultimate failure domain being a single erlang VM operating inside a cluster of erlang VMs, all supported without third party libraries as a part of the way of doing things.