I don't feel like an expert here, but this just seems... wrong.
Some of the arguments made about actors are silly - like, "..extract from it the missile launch codes and launch the missile.." What exactly stops any other function or method from doing something like this? This has nothing to do with actors.
The middle seems to be very specific criticism based entirely on Erlang's model (which I'm not familiar enough with to comment on specifics) and then attributed to the entire theoretical model.
And then the rest of it rambles about pure functions, which again has little or nothing to do with the actor model.
'What exactly stops any other function or method from doing something like this? This has nothing to do with actors.'
Richer type signatures than what you may be used to if you're coming from Java or C++. Haskell can write a function that can guarantee that it can not be used for launching missles (as long as you don't use unsafePerformIO, which I say for completeness, but generally you can ignore this caveat).
This is also related to the pure functions he talks about later; the author basically has a very Haskell/ML view of the world. Which may not be wrong, I'm just trying to contextualize it for you. Anything that doesn't have a strong "pure function" distinction will suffer from the "missile launch" problem, you are correct that doesn't really have anything to do with actors.
I tend to agree that there is a bit of a muddled point here; the author really seems to be driving at saying that pure functions and functions with labeled side effects such as we get in Haskell are what we need to build highly composable software systems. I'm becoming more and more sympathetic to this view over time. But the introduction of actors into this essay as a result ends up being almost an extraneous point to the main point that's trying to come out and I think the clarity suffers greatly. It's not so much anti-Actors as anti-anything-but-pure-functions.
"It's possible there are some other ideas from OO worth salvaging, but more likely I think OO is just an evolutionary dead-end."
I don't know why it is that some functional programmers insist on putting a diatribe against OOP in every little thing they write. I understand where they're coming from, but can they just not fathom that there could be a different way of doing things than what they're used to?
OO is the current dominant programming paradigm and has been for the past ~15-20 years. Functional programmers in general can't help but know about OO; most of them were OO programmers before they became functional programmers. Combined with the fact that being popular has advantages (more people working on core code, an increased ability to get a job in $YOUR_FAVORITE_LANGUAGE), which causes a desire to recruit more to their cause, you end up with a strong likelihood of seeing a recruitment pitch targeted at the largest recruitable demographic. In this case, this means promising fire and brimstone to the OO heretics unless you come to the light of FP. (The linked post is not that strong, but I've seen much stronger.) You generally don't see recruitment pitches for logic programmers or VDHL programmers.
You should listen to the functional programmer's complaints against OO, then make up your own mind. My programming has gotten a lot more functional lately, but there are certain domains where OO really, really shines and I still end up using it there (GUI widgets, etc). It's definitely not the right solution to every problem, though. (I am aware you did not make that argument, I'm just sayin'.)
It's less the strength of the complaint as much as it is the context. If I'm reading an article about the strengths and weaknesses about functional programming vs OOP, it's fine to include such things. However, I think in this post it detracts from the author's main point. By the end of the first few paragraphs, I was focused more on thinking "Oh, this is another of those rants against OOP" than I was on the actual content.
Perhaps you have to hardcode some action to take once the result is available in an FP language. In a late-bound OO language, you just send a message and take whatever action is appropriate based on the state of the program.
Some of the arguments made about actors are silly - like, "..extract from it the missile launch codes and launch the missile.." What exactly stops any other function or method from doing something like this? This has nothing to do with actors.
The middle seems to be very specific criticism based entirely on Erlang's model (which I'm not familiar enough with to comment on specifics) and then attributed to the entire theoretical model.
And then the rest of it rambles about pure functions, which again has little or nothing to do with the actor model.