After using it for years, I can say it does work, but only with a high complexity overhead. Failure conditions, retry logic, serialization and delivery guarantrees are a concern of multi-host parallelism, but not really multicore (same process) parallelism.
I'm not sure I've ever seen an abstraction over memory-separated concurrency that doesn't add a lot of complexity. It may be that such a difference is fundamental and isn't meant to be abstracted over.
In any case, unless you are sure that you want to design for distributed parallelism, I recommend conventional thread pools, etc.
Also, https://www.chrisstucchio.com/blog/2013/actors_vs_futures.ht...
If the Erlang syntax is too weird, Elixir allows you to use ruby-like syntax on the Erlang VM. It also comes with an absolutely amazingly powerful lisp-like macro system.
That said, the fastest computers over the past 5 years or so aren't much faster, but the power usage is much less... For example, the i5-6200u is an absolute beast of a machine for its' power consumption. This is great for server-side computing, where virtualization and other isolation strategies for allowing shared resources work well.
I don't know that we really need too much more in terms of "faster" ... the problems to be solved at this point are absolutely in systems solutions that are distributed and those communication channels. Google can deliver results of a query amazingly fast... We're going to reach a point where communication networks reach nearly every inch of livable space, and all information is (virtually) within arms length.
(divergent rambling ahead)
There are bigger issues at hand... that being physical transportation... we (in the U.S. and many other places) have more pavement for cars that we do housing space. There are optimizations to be had in the physical world that are far more pressing than if computing can get another 4-5 cycles out of moore's law. The costs of food, medication are growing kind of insane the past few years. We're pushing for younger education to the point that little kids are washing out and doing worse, instead of being little kids. On the flip side, they're so isolated that they can't handle genuine pressure/stress later in life. It's a messed up world.
It's convenient that multicore utilization is a scale problem at the same that utilizing networked compute resources (ie in the cloud) is scale problem resources because we might be able to treat them as similar problems. Yes the network introduces some other unique qualities (https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...) but apart from reliability assertions it's an interesting observation that they can be treated similarly if message passing mechanics are abstracted. eg they both fit asynchronous, event driven paradigms. both need elimination of shared state to not make errors in your code (required over the network).
Multicore concurrency in code isn't too hard but threads/locking are probably the wrong abstraction. Similarly, functional approaches might be a better "default" approach for a concurrent world.