3 ms·

Not a guru, but: 1. As with any multithreaded application, if your OS scheduler is heavily loaded by other applications, you can experience issues. Erlang is

Not a guru, but: 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't worry about schedulers of either type except in rare cases. 2. Sending to a larger mailbox doesn'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. 3. You can get Erlang style concurrency out of pony (natively), JVM languages (scala/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't need to combine in any ruby/python/perl, which are all slightly less expressive than Erlang. Calling C code works two ways; you can call it out-of-process via what'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's both an art and a science.

rozap 11y ago
I don't want to be pedantic, but I'm going to be pedantic (sorry!) You can get Erlang style concurrency out of ... JVM languages (scala/akka; quasar) This is a little misleading. Yea, akka gives you actors, and on the surface they look similar to erlang processes (they have a receive block, and a ! function call), but I think the more subtle differences are what make erlang interesting, and ultimately really pleasant to work with 1) akka is not preemptive multitasking. actors are multiplexed across a thread pool, so it's possible to do blocking IO and screw a bunch of other actors up inadvertently 2) the whole gc thing that applies across the vm. all sorts of wonderful things fall out of the two properties above, things which you need to work really hard to get in an akka world. as far as foreign interfaces to python, it's certainly possible with something like jinterface, but I'm not really sure what the point would be. generally you leave erlang behind for similar reasons you might leave python behind (things that are cpu bound). jinterface exists because java does a whole bunch of stuff well that erlang falls down at, so they can complement each other nicely. I'm not sure there are as many of those cases with python.
- phamilton 11y ago
  It is my understanding that quasar gives you something awfully close to preemptive scheduling. It's not quite as strict as Erlang's reduction based appproach, but it essentially provides implicit cooperative scheduling. It allows you to do blocking IO without tying up execution. On top of quasar, using Azul as the garbage collector will get you a GC without Stop-The-World behavior on the JVM. It's neither open source nor cheap though. That said, I'm plenty happy with BEAM.
Matthias247 11y ago
I wouldn't say Pony (which is very interesting!) has the same concurrency style as Erlang. Yes, the both allow to send messages to other processes/actors in an asynchronous (non-blocking) fashion. However Erlang supports also blocking operations (e.g. through a selective receive) beautifully and thereby allows to build blocking APIs on top of non-blocking messaging operations. Pony on the other hand is totally async. There is no way to block an actor for the result, e.g. in order to wait for a response. The only way to get some external input (response) is to give up the current branch of execution (return from the main behavior method) and wait for the next behavior to be executed. Pony is even more strict than other actor frameworks in this regard, because it even won't perform garbage collection inside an actor as long as it is actively running.

rozap 11y ago

I don't want to be pedantic, but I'm going to be pedantic (sorry!) You can get Erlang style concurrency out of ... JVM languages (scala/akka; quasar) This is a little misleading. Yea, akka gives you actors, and on the surface they look similar to erlang processes (they have a receive block, and a ! function call), but I think the more subtle differences are what make erlang interesting, and ultimately really pleasant to work with 1) akka is not preemptive multitasking. actors are multiplexed across a thread pool, so it's possible to do blocking IO and screw a bunch of other actors up inadvertently 2) the whole gc thing that applies across the vm. all sorts of wonderful things fall out of the two properties above, things which you need to work really hard to get in an akka world. as far as foreign interfaces to python, it's certainly possible with something like jinterface, but I'm not really sure what the point would be. generally you leave erlang behind for similar reasons you might leave python behind (things that are cpu bound). jinterface exists because java does a whole bunch of stuff well that erlang falls down at, so they can complement each other nicely. I'm not sure there are as many of those cases with python.

phamilton 11y ago
It is my understanding that quasar gives you something awfully close to preemptive scheduling. It's not quite as strict as Erlang's reduction based appproach, but it essentially provides implicit cooperative scheduling. It allows you to do blocking IO without tying up execution. On top of quasar, using Azul as the garbage collector will get you a GC without Stop-The-World behavior on the JVM. It's neither open source nor cheap though. That said, I'm plenty happy with BEAM.

Matthias247 11y ago

I wouldn't say Pony (which is very interesting!) has the same concurrency style as Erlang. Yes, the both allow to send messages to other processes/actors in an asynchronous (non-blocking) fashion. However Erlang supports also blocking operations (e.g. through a selective receive) beautifully and thereby allows to build blocking APIs on top of non-blocking messaging operations. Pony on the other hand is totally async. There is no way to block an actor for the result, e.g. in order to wait for a response. The only way to get some external input (response) is to give up the current branch of execution (return from the main behavior method) and wait for the next behavior to be executed. Pony is even more strict than other actor frameworks in this regard, because it even won't perform garbage collection inside an actor as long as it is actively running.