I think Akka is sort of heading in the right direction in its ubiquitous language. Akka talks about itself in terms of solving the "distribution problem" - not necessarily across machines but machines OR cores. It talks about "location transparency" as a first principle meaning that an actor/worker that processes a message can be either on another CPU or another physical machine and the location of that actor is transparent from the perspective of the code - it's a deployment/configuration concern.

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.