Why is Akka being marketed as reactive? Is Actor Model reactive

This is a question I am interested in and I have been doing some research on. For other viewpoints, see this blog post by Noel Walsh or this question on Stack Overflow. I have some opinions I would like to offer:

• I think Akka, because it works with messages, encourages a "push mindset". Often, for concurrency, I would argue this is not what you want. Pull is much safer. For example one common pattern for distributed systems is to have a set of workers processing information in a queue. Obviously this is possible in Akka but it doesn't necessarily seem to be the first approach people try. Akka also offers durable mailboxes but again it depends how you use them - a single shared queue is a lot more flexible than per worker queues for balancing / re-assigning work.
• It's easy to get into the mindset of replacing your classes with actors. In fact some people even seem to advocate it by saying actors should only do one thing. Taken to it's logical conclusion this increases code complexity as Jason describes, because if every class is an actor, that's a lot of extra messages and receive / send blocks. It also makes it harder to understand and test the code because you lose the formality of interfaces - and I am not convinced that comments are a solution to this. Also despite Akka's legendary efficiency, I suspect that actor proliferation is not a good idea performance wise - when we use Java threads we know they are precious and conserve them accordingly.
• It's related to the previous point, but another annoyance is the loss of type information that Noel and Pino highlight, as for many of us that's why we are using Scala rather than other languages such as Python. There are some ways around this but they are either non-standard, not recommended or experimental.
• Finally concurrency, even if you have a "let it crash" mindset, is hard. Alternative programming models can help but they don't make the problems go away - they change them - that's why it's good to think about them formally. It's also why Joe Average developer reaches for ready built tools like RabbitMQ, Storm, Hadoop, Spark, Kafka or NoSQL databases. Akka does have some prebuilt tools and components, which is cool, but it also feels quite low level, so more ready built common elements of distributed systems would help developers and ensure systems are built right.

Like Jason, I am keen to hear other people's insight here. How can I address some of the issues above and use Akka better?

Although the Actor Model is older than Erlang, the designers of Erlang only learned about the Actor Model after having designed Erlang, so some differences are to be expected.

They followed parallel paths of evolution, though: the Actor Model was created by Carl Hewitt based on the message passing semantics of Smalltalk. Alan Kay, in turn had based the message passing semantics of Smalltalk on the goal-driven evaluation of PLANNER, which was designed by … Carl Hewitt.

PLANNER was the precursor to Prolog. Erlang was originally not intended to be a language, rather it started out as a library for fault-tolerant distributed programming in Prolog, and later evolved into a dialect of Prolog, before it became its own language, still to this day heavily influenced by Prolog (plus, the original Erlang interpreter was written in Prolog).

So, the similarities between Processes in Erlang, Objects in OO, and Actors in the Actor Model are far from coincidental.

Erlang is a language with several layers, each of which are supersets of the lower layers. The smallest layer is Functional Erlang. This is a standard functional language with some additions inherited from Prolog, such as unification instead of binding/equality. If we add Processes and Messages to that, we get Concurrent Erlang. Throw in remote processes, and you get Distributed Erlang. Now add some libraries and design patterns from the OTP, and you have fault-tolerant Erlang.

Processes are Actors. (They are also Objects.) The inside of Processes is Functional, not Actor-based. The structure of a large fault-tolerant Erlang system constructed using the tools and patterns of the OTP, is often very Object-Oriented.

So, it depends on what scale you are looking at.

In a typical large Erlang system, you have an object-oriented architecture with message-passing actors implemented using functional programming. What OTP calls a server is closely related to an object, servers are made up of processes (which are actors), processes use functions internally.

In general, I don't believe that any pure Actor Language has ever left research. Heck, I don't even know if Carl Hewitt's PLASMA, the original Actor Language was ever even implemented.