I started out my career working at the San Diego Supercomputer Center on some of the very early multiprocessor supercomputers of the day (i.e. when a 1000 cores was a supercomputer). My interest in concurrency started there and eventually lead me to Erlang and Elixir.

While there are some simulations that could effectively use the BEAM, most supercomputer type problems don’t translate well to the actor model due to the connectivity of the data. For large physical simulations, every data point affects the value of every other data point in the simulation.

The Actor model assumes a network of minimal connections. If every process needs to talk to every other process then communication dominates costs as you scale the problem.

Now on the other hand, almost all of the science of numerical computation is figuring out when it’s “okay” to ignore the connections between data in a problem and partition the problem into smaller solvable problems.

I think the BEAM could work in these environments as scheduler and coordinator, but you’d need a specialized core of mathematical routines that currently doesn’t exist.

These supercomputers are working on parallelizable problems, yes, but need raw speed such as for modeling climate change. They might even use specialized languages for the computations. A BEAM language may be good for supervising the process farm but other than that there needs to be mutable data structures and fast matrix computations.

I really do wonder what would happen if we had a pure dependently typed actor-model functional language. This would enable us to use crazy tricks like process-based memoization, and have the compiler do all kind of weird things for us to make programs faster.

It is completely possible to use mutable data structures in a purely functional language by using a State Monad Transformer (But I have to admit, this is the kind of stuff that Mathematics Professors discuss about with squiggely lines and vague terms – I don’t understand how this works myself either right now).