4 ms·

As an outsider, why doesn't/can't Ruby implement a full actor system like Erlang/BEAM? Ruby is already based on message passing so it seems like it should be po

As an outsider, why doesn't/can't Ruby implement a full actor system like Erlang/BEAM? Ruby is already based on message passing so it seems like it should be possible. Granted it'd likely induce a large performance hit since presumably every object would need to be locked or have a message queue.

holstvoogd 6y ago
There are different fully concurrent ruby implementations: truffleruby, rubinius, jruby.. they all suck at what ruby is most used for, running rails. Last time i tried cruby was 10x faster still. So in practice we glady throw more memory and processes at the problem.
- cortesoft 6y ago
  I wonder what percentage of Ruby is rails... I have been using Ruby pretty much every day for work since 2005, and haven't done any rails since 2009. Wonder if I am that much of an anomaly.
  - freedomben 6y ago
    What are you using Ruby for? I have used ruby since 2013 and started on rails but quit using rails in 2015. I still use ruby all the time though, mostly for scripts/automation that violate my rule on bash v. other lang for scripts (basically do I need arrays, maps, or to parse json beyond simple extractions that jq is great at). I do have a couple sinatra services now though that I maintain. Sinatra is wonderful with simple needs like mine. I don't know how much of an anomaly I am though, interested in hearing from others as well. Edit: not looking to debate bash vs other langs here. Of course you're free to do such below, but I won't be engaging (got to focus on work and have had the debate many times and I don't think any of us will ever convince the other. It's become religion at this point). Also I use Elixir/Phoenix these days for use cases that used to be rails
    - cortesoft 6y ago
      A lot of services written with Sinatra, some developer tooling, scripts to maintain our systems.
    - mediaman 6y ago
      Anything you miss from Rails now that you're primarily using Phoenix for those use cases? Elixir/Phoenix does look pretty intriguing to me, though the support universe is smaller. What held me back so far is that a lot of simple B2B, low volume stuff doesn't seem to benefit from the high parallelism that BEAM brings. But I'm wondering if it brings enough other advantages that I shouldn't view it that simplistically.
      - realusername 6y ago
        > But I'm wondering if it brings enough other advantages that I shouldn't view it that simplistically. So to start with, Phoenix LiveView really is a game changer, you should have a look at Elixir just for that. This is the talk which really bluffed me when I first saw it: https://www.youtube.com/watch?v=MZvmYaFkNJI https://www.youtube.com/watch?v=MZvmYaFkNJI. For the other upsides, I like a little bit better the way everything is architectured in Phoenix, there's much less magic and it's easier to follow the data flow and what is going on.
      - lawik 6y ago
        Not the previous commenter. But enthusiastic :) I would recommend trying it and seeing how you like it. I've basically dropped Python which was my daily language in favor of Elixir. I find I get a higher top bound to what I can do, high-level expressive but less magical code and a bunch of capabilities that aren't typically feasible with other runtimes (state handling, resiliency and stuff). The parallelism I get for free with Phoenix whether I try or not. I'd watch Sasa Jurics talk on the heart of elixir and erlang to get more of the technical advantages laid out quite well.
- cpuguy83 6y ago
  What are you doing that cruby is faster? I've run both Rubinius and jruby (with rails), both gave me significant performance gains.
rubyn00bie 6y ago
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.
- elcritch 6y ago
  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.
- ioquatix 6y ago
  We can do the same model for Ruby (preemption of event driven fibers) and may choose to do so in the future. We are just taking one step at a time.
semiquaver 6y ago
Ractors, also introduced in ruby 3.0, are basically this. Ractors work by passing messages or immutable objects. https://github.com/ruby/ruby/blob/master/doc/ractor.md https://github.com/ruby/ruby/blob/master/doc/ractor.md
chrisseaton 6y ago
> As an outsider, why doesn't/can't Ruby implement a full actor system like Erlang/BEAM? Do you really want an actor system? Actors are non-determinsitic, extremely prone to difficult-to-debug race conditions, and inherently stateful. They're a classic concurrency foot-gun from the dark old ways of doing things. Don't we want to be moving away from these models that we know trip people up? Can't we do better than this for Ruby?
- dnautics 6y ago
  You shouldn't use actor systems as a code organization pattern, only in places where async is necessary and in those cases you're going to have to debug race conditions anyways. When that happens you will want an actor system because it will make it easier to understand the data flowing through your system, and especially, effortlessly (0 loc) clean up dangling resources from error conditions and prevent leaks. Moreover Elixir provides you fantastic tools to drive unit and integration testing around your async systems.
- elcritch 6y ago
  > They're a classic concurrency foot-gun from the dark old ways of doing things. Sure you're not thinking of threads? Actor's have only really been done in Erlang, and more recenetly in Akka and Orlean's. AFAIK, there aren't any other paradigms other than CSP or threads for concurrency. Actor's can have race conditions, same as any other concurrent system but I've personally never actually had any given the design patterns in OTP and Elixir. It's really helpful (to me) that each actor is always deterministic in itself and doesn't share data, only messages. It also maps nicely onto multicore.
  - chrisseaton 6y ago
    > Sure you're not thinking of threads? No I'm thinking of actors - stateful, non-determinstic, racey actors. A minefield of classic concurrency bugs! > Actor's can have race conditions, same as any other concurrent system Deterministic systems like fork-join don't ever have race-conditions. > is always deterministic in itself and doesn't share data But the global state of all the actors is shared. If an actor you send a message to responds differently due to its state then let's be honest you're implicitly sharing that state. > It also maps nicely onto multicore. It maps directly to multicore, right. Don't we want something higher level and safer than directly mapping to our hardware?

holstvoogd 6y ago

There are different fully concurrent ruby implementations: truffleruby, rubinius, jruby.. they all suck at what ruby is most used for, running rails. Last time i tried cruby was 10x faster still. So in practice we glady throw more memory and processes at the problem.

cortesoft 6y ago
I wonder what percentage of Ruby is rails... I have been using Ruby pretty much every day for work since 2005, and haven't done any rails since 2009. Wonder if I am that much of an anomaly.
- freedomben 6y ago
  What are you using Ruby for? I have used ruby since 2013 and started on rails but quit using rails in 2015. I still use ruby all the time though, mostly for scripts/automation that violate my rule on bash v. other lang for scripts (basically do I need arrays, maps, or to parse json beyond simple extractions that jq is great at). I do have a couple sinatra services now though that I maintain. Sinatra is wonderful with simple needs like mine. I don't know how much of an anomaly I am though, interested in hearing from others as well. Edit: not looking to debate bash vs other langs here. Of course you're free to do such below, but I won't be engaging (got to focus on work and have had the debate many times and I don't think any of us will ever convince the other. It's become religion at this point). Also I use Elixir/Phoenix these days for use cases that used to be rails
  - cortesoft 6y ago
    A lot of services written with Sinatra, some developer tooling, scripts to maintain our systems.
  - mediaman 6y ago
    Anything you miss from Rails now that you're primarily using Phoenix for those use cases? Elixir/Phoenix does look pretty intriguing to me, though the support universe is smaller. What held me back so far is that a lot of simple B2B, low volume stuff doesn't seem to benefit from the high parallelism that BEAM brings. But I'm wondering if it brings enough other advantages that I shouldn't view it that simplistically.
    - realusername 6y ago
      > But I'm wondering if it brings enough other advantages that I shouldn't view it that simplistically. So to start with, Phoenix LiveView really is a game changer, you should have a look at Elixir just for that. This is the talk which really bluffed me when I first saw it: https://www.youtube.com/watch?v=MZvmYaFkNJI https://www.youtube.com/watch?v=MZvmYaFkNJI. For the other upsides, I like a little bit better the way everything is architectured in Phoenix, there's much less magic and it's easier to follow the data flow and what is going on.
    - lawik 6y ago
      Not the previous commenter. But enthusiastic :) I would recommend trying it and seeing how you like it. I've basically dropped Python which was my daily language in favor of Elixir. I find I get a higher top bound to what I can do, high-level expressive but less magical code and a bunch of capabilities that aren't typically feasible with other runtimes (state handling, resiliency and stuff). The parallelism I get for free with Phoenix whether I try or not. I'd watch Sasa Jurics talk on the heart of elixir and erlang to get more of the technical advantages laid out quite well.
cpuguy83 6y ago
What are you doing that cruby is faster? I've run both Rubinius and jruby (with rails), both gave me significant performance gains.

rubyn00bie 6y ago

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.

elcritch 6y ago
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.
ioquatix 6y ago
We can do the same model for Ruby (preemption of event driven fibers) and may choose to do so in the future. We are just taking one step at a time.

semiquaver 6y ago

Ractors, also introduced in ruby 3.0, are basically this. Ractors work by passing messages or immutable objects. https://github.com/ruby/ruby/blob/master/doc/ractor.md https://github.com/ruby/ruby/blob/master/doc/ractor.md

chrisseaton 6y ago

> As an outsider, why doesn't/can't Ruby implement a full actor system like Erlang/BEAM? Do you really want an actor system? Actors are non-determinsitic, extremely prone to difficult-to-debug race conditions, and inherently stateful. They're a classic concurrency foot-gun from the dark old ways of doing things. Don't we want to be moving away from these models that we know trip people up? Can't we do better than this for Ruby?

dnautics 6y ago
You shouldn't use actor systems as a code organization pattern, only in places where async is necessary and in those cases you're going to have to debug race conditions anyways. When that happens you will want an actor system because it will make it easier to understand the data flowing through your system, and especially, effortlessly (0 loc) clean up dangling resources from error conditions and prevent leaks. Moreover Elixir provides you fantastic tools to drive unit and integration testing around your async systems.
elcritch 6y ago
> They're a classic concurrency foot-gun from the dark old ways of doing things. Sure you're not thinking of threads? Actor's have only really been done in Erlang, and more recenetly in Akka and Orlean's. AFAIK, there aren't any other paradigms other than CSP or threads for concurrency. Actor's can have race conditions, same as any other concurrent system but I've personally never actually had any given the design patterns in OTP and Elixir. It's really helpful (to me) that each actor is always deterministic in itself and doesn't share data, only messages. It also maps nicely onto multicore.
- chrisseaton 6y ago
  > Sure you're not thinking of threads? No I'm thinking of actors - stateful, non-determinstic, racey actors. A minefield of classic concurrency bugs! > Actor's can have race conditions, same as any other concurrent system Deterministic systems like fork-join don't ever have race-conditions. > is always deterministic in itself and doesn't share data But the global state of all the actors is shared. If an actor you send a message to responds differently due to its state then let's be honest you're implicitly sharing that state. > It also maps nicely onto multicore. It maps directly to multicore, right. Don't we want something higher level and safer than directly mapping to our hardware?