Well... the big reason almost no runtime/vm provides what erlang does is because BEAM will preempt a running actor if it takes too long (uses up its operation budget more or less). Ruby only provides mechanisms for cooperatively scheduled execution. That is to say, and this is the big problem with async most everywhere except Erlang/BEAM, a task will block everything else from executing until its finished and yields to another fiber/thread.
Shrug Having tried like every possible method of async I/O with Ruby to eek out moar good perfz back in the day... including various actor implementations (sup, JRuby and Akka)... nothing compares to just using BEAM if you want the actor paradigm. The cooperative scheduling problem is a really enormous pain in the ass most of the time.
That's part of my question (to me at least) is why they couldn't implement preemptive actors? At least at the granularity of individuals methods which in Ruby is pretty much any action, right? Async and the whole red/blue function problem seems like a pain.
Shrug Having tried like every possible method of async I/O with Ruby to eek out moar good perfz back in the day... including various actor implementations (sup, JRuby and Akka)... nothing compares to just using BEAM if you want the actor paradigm. The cooperative scheduling problem is a really enormous pain in the ass most of the time.