I'm not convinced the Actor model is a concurrency silver bullet. I'm using it in Scala, and you still have race conditions and potential deadlocks to worry about.
It helps to 'segregate' your application so it's easier to reason about what data could be a race sometimes, but for me it just made multithreaded applications a little less hard, not easy.
The way I like to put it is that it takes concurrency from an exponential problem that no human can actually solve, to a polynomial one. It isn't a magic bullet, because nothing can truly fully abstract away concurrency, but at least it's in the class of sane answers.
This is grounded in the arguments about how many paths through your program there are; with conventional threading, it's exponential since at any time any thread may reach out and twiddle with something another thread has. Things that isolate threads confine interactions to just their communication points, which is more polynomial than exponential. You can still get yourself in trouble, but at least you don't start out in trouble.
A secret of rock solid concurrency is communication, but there are many sane concurrency models. Consider people are already fast efficient safe sane code over hundreds of cores on GPU's which looks nothing like Erlang. Still, when you actually start to care that your concurrent code is accurate not just FAST you need to validate your calculations and Erlang does little to help you there. So sure it's better than C, but turn up the memory errors and it still falls down hard.
It helps to 'segregate' your application so it's easier to reason about what data could be a race sometimes, but for me it just made multithreaded applications a little less hard, not easy.