I wouldn't say that ruby has "got past its GIL problems with Ractor" -- you can run very little actually pre-existing libraries with ractors, because it requires no references to global state, and most non-trivial existing code ends up referencing global state (for configuration, caching, etc).
It requires a different approach to writing code than has historically been done in ruby, to scrupulously identify all global state and make it ractor-safe. The ruby ractor implementation doesn't allow existing code to "just work".
Some of these patterns and mitigations and best approaches for cost/benefit are still being worked out.
At this point ractor is early in the experimental stage. It's not like existing applications can currently just "switch to ractor", and problem solved. There is little if any real-world production code running on ractors at present.
But yes, this article's description of the work on "subinterprters" does sound very much like ruby ractors:
> The idea is to have multiple interpreters within the same process. Threads within one interpreter still share the GIL, but multiple interpreters can run parallel. No GIL is needed to synchronize interpreters because they have no common global state and do not share Python objects. All global state is made per-interpreter, and interpreters communicate via message passing only
Yep, that's how ruby ractors work... except that I'm not sure I'd say "all global state is made per-interpreter", ractors still have global state... they just error if you try to access it in (traditional) unsafe ways! I am curious if python's implementation has differnet semantics.
In general, I'd be really excited to see someone write up a comparison of python and ruby approaches here. They are very similar languages in the end, and have a lot to learn from each other, it would be interesting to see how differences in implementation/semantic choices here lead to different practical results. But it seems like few people are "expert" in both languages, or otherwise have the interest, to notice and write the comparison!
Ok, not "solved" in a "everything just works and nobody notices" way, but they have a way forward. The "shared-nothing Actors" model is well demonstrated to work well in Erlang, Elixir etc., so it seems like a reasonable way forward for a language like Ruby or Python.
It's way easier when you bake it into the design of the language from the start, and make it part of the conventions of the ecosystem.
But yeah, "seems like a reasonable way forward" is a far cry from "has got past it"!
I agree it seems like a reasonable way forward, but whether it will actually lead to widepread improvements in actually-existing ruby-as-practiced, and when/how much effort it will take to get there, is I think still uncertain. It may seem reasonable way forward, but it's ultimate practical success is far from certain.
(If this were 20 years ago, and we were designing the ruby language before it got widespread use -- it would be a lot easier, and even more reasonable! matz has said threads are one of the things he regrets most in ruby)
Same for python. It does seem Python is exploring a very similar path, as mentioned in the OP, so apparently some pythonists agree it seems like a reasonable way forward! I will be very interested to compare/contrast the ruby and python approaches, see what benefits/challenges small differences in implementation/semantics might create, or differences in the existing languages/community practices, especially with regard to making actual adoption in the already-existing ruby/python ecosystems/communities more likely/feasible.
It requires a different approach to writing code than has historically been done in ruby, to scrupulously identify all global state and make it ractor-safe. The ruby ractor implementation doesn't allow existing code to "just work".
Some of these patterns and mitigations and best approaches for cost/benefit are still being worked out.
At this point ractor is early in the experimental stage. It's not like existing applications can currently just "switch to ractor", and problem solved. There is little if any real-world production code running on ractors at present.
But yes, this article's description of the work on "subinterprters" does sound very much like ruby ractors:
> The idea is to have multiple interpreters within the same process. Threads within one interpreter still share the GIL, but multiple interpreters can run parallel. No GIL is needed to synchronize interpreters because they have no common global state and do not share Python objects. All global state is made per-interpreter, and interpreters communicate via message passing only
Yep, that's how ruby ractors work... except that I'm not sure I'd say "all global state is made per-interpreter", ractors still have global state... they just error if you try to access it in (traditional) unsafe ways! I am curious if python's implementation has differnet semantics.
In general, I'd be really excited to see someone write up a comparison of python and ruby approaches here. They are very similar languages in the end, and have a lot to learn from each other, it would be interesting to see how differences in implementation/semantic choices here lead to different practical results. But it seems like few people are "expert" in both languages, or otherwise have the interest, to notice and write the comparison!