Ah, true; this whole thing makes very little sense for the general case. Most workloads aren&#x27;t like this.<p>The real goal here, in my mind, was to allow people in those particular high-performance domains (gaming especially, though the other ones would probably benefit too) to code at a higher abstraction level.<p>In my ideal world, a physics engine, for example, would be implemented in code as actors sending messages—with one actor for each physical (e.g. collide-able) object. Not only is that really expensive; the naive approach wouldn&#x27;t even work! (You need &quot;tick&quot; events spammed to every physics-actor once per frame, which is just absolutely ridiculous.) But then the compiler transparently takes that and <i>spits out</i> something that isn&#x27;t actor-modelled at all, but rather is a modern-day physics engine doing GPGPU SIMD to arrays of quaternions.<p>Or, in short: I want to code games in Elixir, without an impedance mismatch in the places where one of my actors&#x27; components turns out to need groupwise synchronous shared-memory evaluation rather than piecewise asynchronous reduction-scheduled evaluation. (That sounds like something that should be followed up with &quot;and a pony!&quot;, but—given that the Erlang BEAM VM already has the infrastructure of &quot;dirty&quot; schedulers for CPU-bound tasks, and an LLVM IR step in its JIT which could be shunted over to a PTX-ISA target—this actually shouldn&#x27;t even be that hard an extension to make.)