7 ms·

ractors, due to its "no shared or immutable only memory" constraints, is fundamentally incompatible with 99% of ruby code in the wild. I don't see it getting mu

by chucke 4y ago

ractors, due to its "no shared or immutable only memory" constraints, is fundamentally incompatible with 99% of ruby code in the wild. I don't see it getting much adoption until some of those constraints are relaxed.

LAC-Tech 4y ago
If that constraint is relaxed, then they aren't really actors anymore, are they?
- chucke 4y ago
  They would. Some of the constraints were senseless. You used to not be able to use class variables, even if they were already initialized and frozen. However, using static variables, and worse, changing them, was fine. Ruby uses a lot of pure lazy memorization. That's an aspect I'd like to see more accepted. A system that enforces rather than recommends, is a less usable system.
t-writescode 4y ago
This can be said of most actor systems. Using actors is a fundamentally different way of programming than non-actor-based multi-threaded systems. You do have to change your paradigm; but, when I have, I've found the experience to be really wonderful.
- RussianCow 4y ago
  > This can be said of most actor systems. True, but other languages/platforms have better built-in support for immutable data structures and don't force you to fight the standard library to implement a share-nothing approach.
  - t-writescode 4y ago
    You get there pretty fast in Ruby with DryStruct; and, Ruby has .freeze, which can also be helpful.
    - RussianCow 4y ago
      But you can't use any libraries that maintain mutable state, which, in Ruby land, is many of them.
      - t-writescode 4y ago
        A common actor strategy for that is to have a dedicated actor for communicating with that mutable state
- chucke 4y ago
  Celluloid was an actor library which worked well with most ruby code. This is not the case for ractor. For starters, the ruby standard library is itself incompatible with ractor. Go ahead and try using logger inside one. Beyond that, a lot of mature libraries would have to be rewritten to fit ractors, and that's quite risky. Something as simple as a connection pool has to be done completely differently. That's a big red flag, considering that the value of ruby is its ecosystem. I actually tried making the libs I maintain ractor compatible. I recorded the constraints and suggested removing some of fhe annoying ones. Some got accepted, but it's not enough.

by chucke 4y ago

LAC-Tech 4y ago

If that constraint is relaxed, then they aren't really actors anymore, are they?

chucke 4y ago
They would. Some of the constraints were senseless. You used to not be able to use class variables, even if they were already initialized and frozen. However, using static variables, and worse, changing them, was fine. Ruby uses a lot of pure lazy memorization. That's an aspect I'd like to see more accepted. A system that enforces rather than recommends, is a less usable system.

t-writescode 4y ago

This can be said of most actor systems. Using actors is a fundamentally different way of programming than non-actor-based multi-threaded systems. You do have to change your paradigm; but, when I have, I've found the experience to be really wonderful.

RussianCow 4y ago
> This can be said of most actor systems. True, but other languages/platforms have better built-in support for immutable data structures and don't force you to fight the standard library to implement a share-nothing approach.
- t-writescode 4y ago
  You get there pretty fast in Ruby with DryStruct; and, Ruby has .freeze, which can also be helpful.
  - RussianCow 4y ago
    But you can't use any libraries that maintain mutable state, which, in Ruby land, is many of them.
    - t-writescode 4y ago
      A common actor strategy for that is to have a dedicated actor for communicating with that mutable state
chucke 4y ago
Celluloid was an actor library which worked well with most ruby code. This is not the case for ractor. For starters, the ruby standard library is itself incompatible with ractor. Go ahead and try using logger inside one. Beyond that, a lot of mature libraries would have to be rewritten to fit ractors, and that's quite risky. Something as simple as a connection pool has to be done completely differently. That's a big red flag, considering that the value of ruby is its ecosystem. I actually tried making the libs I maintain ractor compatible. I recorded the constraints and suggested removing some of fhe annoying ones. Some got accepted, but it's not enough.