Not a guru, but:<p>1.  As with any multithreaded application, if your OS scheduler is heavily loaded by other applications, you can experience issues.  Erlang is designed to degrade fairly slowly and fairly gracefully before it has to give up.  From a complexity standpoint, the programmer doesn&#x27;t worry about schedulers of either type except in rare cases.<p>2.  Sending to a larger mailbox doesn&#x27;t take more resources, it takes more reductions.  So if a process has a large mailbox, it costs the sender more to add yet another message into the mailbox.  This is a form of backpressure and helps slow down the system in a gentle(r) way when a single process is bottlenecking.<p>3.  You can get Erlang style concurrency out of pony (natively), JVM languages (scala&#x2F;akka; quasar), but I doubt you could get it out of Python unless you reimplemented Python on the BEAM or Java VM.  Generally I find personally that working directly in Erlang is fine and I don&#x27;t need to combine in any ruby&#x2F;python&#x2F;perl, which are all slightly less expressive than Erlang.<p>Calling C code works two ways; you can call it out-of-process via what&#x27;s called a port, which is basically a unix pipe to your C process; or in-process via a NIF, which is more dangerous because the scheduler has no control or understanding inside your C code.  Carefully written NIFs, and NIFs written to take advantage of the dirty scheduling system, can thrive, but it&#x27;s both an art and a science.