The thesis of the author is: There is at least one problem, which can be done better with a ConcurrentHashMap than with Actors. I do not see, why you cannot re

The thesis of the author is: There is at least one problem, which can be done better with a ConcurrentHashMap than with Actors. I do not see, why you cannot replicate the ConcurrentHashMap behavior in Erlang? > Now, you could do some clever stuff and partition the map up into N actual maps, one for each of N processes and farm the requests out to the set of processes based on the hash-code. But that’s getting complex[...]. Well, his problem seems to be that nobody has already included something like this in Erlang/OTP, whereas there is java.util.concurrent.ConcurrentHashMap since Java 5. That is an issue with the standard library, but not a flaw of the Actor model. This "clever stuff" is present in ConcurrentHashMap, too.