> Also, just so that we understand each other: I'm a big fan of the BEAM.

We probably should've established this way earlier, sorry if I came across as pretentious or off putting.

I'll answer in a bit of reverse order.

> I just want to explain why I believe that function coloring (or however you call it) can never be conceptionally be removed from a language if sync/async is to be supported.

To respond in more of a roundabout way, why doesn't C have colouring issues if it too supports asynchronicity (I'm pretty sure I've made up a word but hope the point gets accross fine) via pthreads?

The colouring issue is, at least under my understanding of C#'s async/await system is to accommodate for the fact that Rosyln transforms the C# source into .NET IL with a state machine. It's, to me at least, just a consequence from what layer of the stack we talk at. Erlang doesn't need to worry about since the runtime was designed to run with this specific model of concurrency in mind; but if we look at C#, .NET only supports using OS threads (though David Fowler is investigating green threads in the, iirc, labs repository on the DotNet Github) the async/await is, for lack of a more better word, bolted on. It's to my understanding that IronPython (or maybe it was PythonNet) has difficulties calling into C# async for that reason; though if I'm wrong please correct me.

> is the sole purpose of the existance of those primitives to change performance characteristics? If not, what is the purpose of its existence then?

Fault tolerance, latency, scalability, perhaps minor throughput increases (yeah this is a bit of a contradiction to what I said earlier, but I've revised my opinion that you wouldn't see massive performance gains unless resorting to NIFs).

The Phoenix Framework's 2 million websocket connection challenge I think is a best demonstrator for the use case of BEAM processes. A specific websocket connection dies? No problem, the Supervisor respawns it. Two million connections receiving a Wikipedia length article on a topic without the entire system coming to a crawl? No problem. There isn't a need to worry about kqueue, poll/epoll, or IOCP here, just fire off a task for the purpose and let it do it's thing.

But overall you wouldn't spawn a BEAM process just so you could compute the matrices behind RAID6/RAIDZ2, you'd delegate those to NIFs. The biggest gains in overall performance came from BeamAsm instead.

> Okay, let me follow up on this one. So could we take arbitrary Erlang/Elixir programs and automatically/mechanically rewrite them to push previously inlined calculations to be run on a different process (using spawn) or the otherway around - and that without causing any observable difference in behaviour in any situation except for difference in performance?

Yes. Using the case of the 2 million websocket connection challenge earlier, it doesn't really matter if each of those connections spawned another process as part of its routines, the other processes don't know and don't care. Taking a more generic case of Elixir's GenServers (or gen_server in Erlang), when I perform a call (as in the GenServer behaviour) it doesn't matter to the calling process what happens behind the scenes, it just blocks and waits for a response. The GenServer could fire off any number of processes it wants but the calling process doesn't care about that.