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

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

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.

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.

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.

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.

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.

Interesting idea, but I'm not sure I agree. I was doing a lot of telephony/mobile back in those early 1990s and there was a huge amount of formalism. We tried to model everything as FSM that transitioned states based on received messages. We even used code generators to generate code directly from diagrams. I believe Erlang grew out of that same approach. And initially, systems that failed would simply restart by default.

Then the idea of adding a supervising and observability was a natural addition to these systems.

That said, I think OTP is a great tool for modeling failure domains and I think it does a great job.