Ya functional programming is key, as it's equivalent to a spreadsheet or digital circuit. In other words, it removes the element of time and often dynamic state, which imperative programming generally fails to do.

IMHO most concurrency problems don't actually need async behavior, they need higher-order methods and models which behave deterministically by encapsulating async behavior internally.

Another maturing solution is to use SAT solvers to prove that all exceptional behavior and failure modes are handled. I'm hopeful that AI will help with that and allow us to exercise programs fully, rather than rely on unit tests and fuzzing.

Personally I think that the UNIX model of orchestrating small async programs that do one thing well is the only proven mainstream solution. Erlang and Go come really close, but unfortunately we need a hybrid of the two, which doesn't currently exist. The pattern for that is functional core, imperative shell. Which mimics the real world where business logic can be formerly proven correct or constrained by types and categories, then we wire up programs cookie cutter style. That avoids the use of monads (promises/futures in imperative languages), which are the main footguns. The closest language that does that is ClojureScript, whose runtime is analogous to suspending and resuming a coroutine or green thread that makes Lisp calls (although that's a poor fit and I'm sure I'm wrong about it).

But you're right that we don't currently have a language that can recruit multicore CPUs. I used MATLAB/GNU Octave in the past, but think that Julia probably has a brighter future since it can already run on GPU mostly unmodified. I would not try to do it with a mainstream language like C# or Python, or even PHP for that matter. Although some of PHP's multiprocessing metaphors are pretty solid, since they intentionally use processes instead of threads like in Ruby. There the problem is latency introduced by poor process models used by Microsoft and Apple, not something fundamental with spawning processes. Real-time Linux attempts to unify the kernel under one process model to provide deterministic timing, which is hard enough for regular Linux and probably out of reach of the big OS companies, because money can't buy everything.