I only ever toyed with Scala, and Akka, so I can't really speak too much to it, but it struck me that what I liked most about it was what Erlang simply ~is~.
I think the main difference to me was that Erlang was built from the ground up for fault tolerance. Everything about it is structured around that; you get process isolation and concurrency because of the need to not have one error/exception kill everything, you get distribution because you need hardware/VM issues to not kill everything. Akka's motivation isn't that; it can't do that. The JVM doesn't allow for process isolation, there's one shared heap, etc, so it really does matter what is running locally vs what is running on other machines, you have to be careful about mixing concurrency patterns and using vars, and it is possible for one process to die and take down others with it.
Akka is a little alien to me as well; things like 'become' seems a bit heavy handed (I believe it's due to the JVM not supporting tail call optimization, and Scala can't trampoline the calls if it doesn't know what you're trying to do). Similarly, the reactive nature of actors in Akka, where they don't do anything until they receive a message, while superficial, still bothers me a little bit.
My mental model of an actor in Erlang is simply a lightweight process that executes a function, that has a queue attached; at any point the process can check its queue, and if it needs to repeat itself or change its behavior, you call itself or a different function. It's a very simple mental model that all the OTP behaviors build on. Akka instead has (necessarily) various syntaxes; you're creating this ~thing~ first, setting up all the things it can do, and then it sits waiting for a message to start executing. It's trivial to transcribe one mental model to the other, but I find Erlang's is the one I think best in.
Now, that said, provided you don't need the soft realtime performance of Erlang, Scala/Akka is generally going to be more performant when it comes to number crunching; it's easier to just do it natively in Scala/Akka than have to do it externally in Erlang and open a port.
Scala/Akka benefits from existing JVM expertise which most devs have a bit of; the Erlang VM has its own deep knowledge you have to learn to run it in production (that said, the introspection you have into it is -killer-).
Scala/Akka is easier to transition people to, due to the OOness ("squint a bit and it can kinda be written like Java!"), but I think making a clean break of things with Erlang helped me; even the 'strange' syntax was helpful in that I didn't assume false familiarity due to syntax that seemed familiar (except for 'if'; everyone misuses that at least once). But if a dev finds that way of thinking alien to them, in the Erlang world they're just not going to be that productive; in Scala, you can mix paradigms and they'll likely see better productivity in areas of the code that are still very OO and imperative. I tend to feel there be dragons in OO, imperative code, but the reality is a lot of shops don't have the leisure to write everything in a functional manner, and to pick and choose who works on it based on their familiarity with that paradigm.
There are a few other odds and ends; Scala allows operator overloading which I need so rarely that opening it up is a con in my book, there's a lot of implicit stuff (apply for instance) that while really cool, allows for a lot of hidden dragons to be buried in a large, shared codebase, I really wish Erlang was statically typed as I said before, etc, but those are the main.
I think the main difference to me was that Erlang was built from the ground up for fault tolerance. Everything about it is structured around that; you get process isolation and concurrency because of the need to not have one error/exception kill everything, you get distribution because you need hardware/VM issues to not kill everything. Akka's motivation isn't that; it can't do that. The JVM doesn't allow for process isolation, there's one shared heap, etc, so it really does matter what is running locally vs what is running on other machines, you have to be careful about mixing concurrency patterns and using vars, and it is possible for one process to die and take down others with it.
Akka is a little alien to me as well; things like 'become' seems a bit heavy handed (I believe it's due to the JVM not supporting tail call optimization, and Scala can't trampoline the calls if it doesn't know what you're trying to do). Similarly, the reactive nature of actors in Akka, where they don't do anything until they receive a message, while superficial, still bothers me a little bit.
My mental model of an actor in Erlang is simply a lightweight process that executes a function, that has a queue attached; at any point the process can check its queue, and if it needs to repeat itself or change its behavior, you call itself or a different function. It's a very simple mental model that all the OTP behaviors build on. Akka instead has (necessarily) various syntaxes; you're creating this ~thing~ first, setting up all the things it can do, and then it sits waiting for a message to start executing. It's trivial to transcribe one mental model to the other, but I find Erlang's is the one I think best in.
Now, that said, provided you don't need the soft realtime performance of Erlang, Scala/Akka is generally going to be more performant when it comes to number crunching; it's easier to just do it natively in Scala/Akka than have to do it externally in Erlang and open a port.
Scala/Akka benefits from existing JVM expertise which most devs have a bit of; the Erlang VM has its own deep knowledge you have to learn to run it in production (that said, the introspection you have into it is -killer-).
Scala/Akka is easier to transition people to, due to the OOness ("squint a bit and it can kinda be written like Java!"), but I think making a clean break of things with Erlang helped me; even the 'strange' syntax was helpful in that I didn't assume false familiarity due to syntax that seemed familiar (except for 'if'; everyone misuses that at least once). But if a dev finds that way of thinking alien to them, in the Erlang world they're just not going to be that productive; in Scala, you can mix paradigms and they'll likely see better productivity in areas of the code that are still very OO and imperative. I tend to feel there be dragons in OO, imperative code, but the reality is a lot of shops don't have the leisure to write everything in a functional manner, and to pick and choose who works on it based on their familiarity with that paradigm.
There are a few other odds and ends; Scala allows operator overloading which I need so rarely that opening it up is a con in my book, there's a lot of implicit stuff (apply for instance) that while really cool, allows for a lot of hidden dragons to be buried in a large, shared codebase, I really wish Erlang was statically typed as I said before, etc, but those are the main.