3 ms·

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

• 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.