Hacker News Reader

Comment by mdhb | Hacker News Reader

Quick question for the current Ruby community:

I kind of moved away from Ruby right around the time Ractors were about to land and they looked really promising.

I was just curious if they ended up delivering much in the way of change and if not what the main problems were?

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.

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

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.

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.

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

You get there pretty fast in Ruby with DryStruct; and, Ruby has .freeze, which can also be helpful.

But you can't use any libraries that maintain mutable state, which, in Ruby land, is many of them.

A common actor strategy for that is to have a dedicated actor for communicating with that mutable state

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.

Ractors is still in experimental stage but I’ve played around with it and it sure offers a huge performance benefit & true concurrency

I assume by the fact they are still experimental that there isn’t much in the way of adoption yet?

I was looking into this question a few weeks ago and couldn't find any libraries I would use in typical applications (eg. background jobs, etc) implementing Ractors.

There are occasional comments in GH issues discussing the possibility of implementing Ractors, but nothing material.

Here's one that sounds like exactly the sort of example you had in mind: https://github.com/okeeblow/DistorteD/tree/NEW%E2%80%85SENSA...

Disclaimer: mine :)

Thank you! Will check it out.

Feel free to email me @ the address in the commits if you have questions. I like Ractors a lot and want to see them succeed!

Not from what I have seen, It’s kinda risky because the fact that Ractors still is in experimental stage means that there couls be major breaking changes at any time, both how you use it and internally.

Reply on news.ycombinator.com