&gt; 1) A lot of this sounds like OS style scheduling.<p>This is probably a mixed bag. On a machine that&#x27;s devoted to software in Erlang, you will ideally run one scheduler (OS thread) per core pinned to a core, plus however many dirty&#x2F;async&#x2F;io schedulers needed&#x2F;configured.  You&#x27;ll also have a couple other OS processes running (ntpd, sshd, crond, etc). So the OS will have an easy time with scheduling processes, the majority of the time you&#x27;ll have one thread to run on the core, or one thread on the core waiting for io &#x2F; other signals. On the other hand, you do have Erlang doing work that the OS could conceivably do; but I wouldn&#x27;t really want to put one million threads into an OS scheduler (maybe it works, but I don&#x27;t know).<p>&gt; 2) sending to a larger mailbox takes more resources<p>As felix said, it costs more reductions, but there might be a real cost too; a larger mailbox probably means more senders sending (although it can also just mean slow processing), and if there are more senders sending to the process, there is more contention on the message queue lock, more info on how messages are added to a mailbox here[1]. There&#x27;s not a concept of mailbox capacity, the queue is a linked list; any mailbox can expand until you run out of swap, or hit the configured memory limit, either way the whole OS process dies[2]. I&#x27;d guess the reduction cost for sending a message is a function of the number of messages in the queue, it&#x27;s possible it&#x27;s a function of the total size of all the messages, but I don&#x27;t know if that&#x27;s tracked.<p>Edit: i meant to address &gt; 3) Are there foreign function interfaces that could allow you to get Erlang style concurrency with other languages<p>Not that I&#x27;ve seen. You can do NIFs, ports, or port drivers, but that doesn&#x27;t really get what you&#x27;re asking for. There are some other languages that run on the BEAM VM, maybe one of the Lisps you could take existing Lisp code and run it, but generally the BEAM languages are not available outside the BEAM. If you wanted to run an existing language within BEAM, that language would need to have hooks to embed in another program, and the hooks would need to let you do a small amount of work at a time; or you&#x27;d have to re-implement the language in a BEAM friendly manner.<p>[1] <a href="http:&#x2F;&#x2F;erlang.org&#x2F;pipermail&#x2F;erlang-questions&#x2F;2011-September&#x2F;061050.html" rel="nofollow">http:&#x2F;&#x2F;erlang.org&#x2F;pipermail&#x2F;erlang-questions&#x2F;2011-September&#x2F;...</a><p>[2] This isn&#x27;t very great, and one of the areas where Erlang&#x27;s isolation is weak -- one Erlang process can eat all of limited global resources, for example ram, ports, ets tables, atoms and the result is often the whole VM stops, either it directly exits, or core applications will shutdown when they hit a failure they can&#x27;t handle (for example mnesia really needs to be able to have the ets tables and file ports it needs, and will shutdown when it can&#x27;t get them, often this will result in your application crashing enough to get shutdown)