It appears that the author’s main complaint about Actors, I think more specifically Erlang, is that it does not have a type system similar to Haskell. They want something that is able to track side effects. The only argument they make against Actors is their claim that they are not composable.
So what makes actors not composable? Well, an actor (and an Erlang process) is constructed from a function A => Unit. That this function returns Unit rather than a meaningful type means that it must hardcode some action to take once the result (whose type is not even shown) is available. It is this unfortunate property that destroys any chance we have at combining actors in any sort of general way like we would in a typical combinator library.
This is basically saying that any language that does not track side effects in the type system (which is currently the vast majority of languages) does not compose because something could, somewhere, return the equivalent of Unit. And yet people are still writing large software systems in languages without any real type system.
I think this is an unfortunate piece written by someone that thinks the only way to write software is with an HM-style type system.
I should also add that I don’t think Actors are the be-all and end-all of concurrent software systems. But as someone that has been using Erlang and Elixir almost exclusively at work for a few years, I think it is pretty great at what it does.
Quick Edit
I think the author should have made the title “Actors are not the best concurrency model”. They even say themselves “I don’t know exactly what the replacement looks like yet”. I’m all for finding better abstractions, but to say something isn’t good because of a single issue you have with it is, in my opinion, going overboard.
I never used Erlang, nor have I used any of these modern statically typed languages. However, it sounds weird to me to say that because I can’t assert that a function has no side effects, or because I don’t have type information about it, I can’t combine/reuse them. People combine functions in Python all the time, there are whole frameworks built on top of decorators, which are basically high order functions.
Granted, lots of arguments can be made that this is more fragile or less maintainable than using a statically typed language, but it doesn’t stop people from reusing code in these languages, nor does it stop them from shipping some pretty big systems in it. All in all, it seems like a non-sequitur to say that lacking type information or not being side-effect free makes composability impossible.
And secondly, even if it was impossible to compose functions without static type information, not all actor systems have to be dynamic. Pony comes to mind as a actor-based language with static typing, and there’s that framework in Scala that I forget the name and can’t be bothered to google right now.
It appears that the author’s main complaint about Actors, I think more specifically Erlang, is that it does not have a type system similar to Haskell. They want something that is able to track side effects. The only argument they make against Actors is their claim that they are not composable.
This is basically saying that any language that does not track side effects in the type system (which is currently the vast majority of languages) does not compose because something could, somewhere, return the equivalent of
Unit. And yet people are still writing large software systems in languages without any real type system.I think this is an unfortunate piece written by someone that thinks the only way to write software is with an HM-style type system.
I should also add that I don’t think Actors are the be-all and end-all of concurrent software systems. But as someone that has been using Erlang and Elixir almost exclusively at work for a few years, I think it is pretty great at what it does.
Quick Edit
I think the author should have made the title “Actors are not the best concurrency model”. They even say themselves “I don’t know exactly what the replacement looks like yet”. I’m all for finding better abstractions, but to say something isn’t good because of a single issue you have with it is, in my opinion, going overboard.
I never used Erlang, nor have I used any of these modern statically typed languages. However, it sounds weird to me to say that because I can’t assert that a function has no side effects, or because I don’t have type information about it, I can’t combine/reuse them. People combine functions in Python all the time, there are whole frameworks built on top of decorators, which are basically high order functions.
Granted, lots of arguments can be made that this is more fragile or less maintainable than using a statically typed language, but it doesn’t stop people from reusing code in these languages, nor does it stop them from shipping some pretty big systems in it. All in all, it seems like a non-sequitur to say that lacking type information or not being side-effect free makes composability impossible.
And secondly, even if it was impossible to compose functions without static type information, not all actor systems have to be dynamic. Pony comes to mind as a actor-based language with static typing, and there’s that framework in Scala that I forget the name and can’t be bothered to google right now.