Ruby 3.0.0 RC1

From an implementation perspective this has much more in common with Go than either Python or Node.

In Go, you simply write a blocking IO call, and the scheduler in the Go runtime pauses your current lightweight thread ("parks the go routine" in their terminology) until the IO operation has some results to read. While waiting, the runtime is free to run any other go routine(s) on any number of OS threads.

What is coming to Ruby is a similar system, but where a library can provide this scheduler functionality. So when a lightweight thread (a "Fiber" in Rubys terms) calls a blocking operation, the runtime is notified, and can manage the IO operation while running other fibers.

As another commenter mentioned, there was a similar thing named gevent implemented for Python some years ago, but it didn't become "the way" to do things. I feel there are three main reasons it didn't catch on:

1. A lot of Python programs had blocking IO being performed inside native extensions (e.g. bindings to C/C++ database drivers). If you depended on such a library, the benefits of gevent were severely limited because it's runtime couldn't intercept the IO operations.

2. It was never part of the stdlib, so there was not a huge amount of incentive for the aforementioned driver authors to support it explicitly.

3. There were not that many examples of successful implementation of this model at the time. Go was around but pre 1.0 and not nearly as popular as it is now. Lua was also around, but again, not extremely well known.

I expect that Ruby will also suffer a bit from #1, but hopefully, by providing this concept as part of the language and standard library, problem #2 will be mitigated. #3 is IMO a thing of the past, while I'm not a huge Go fan, it does serve as a compelling argument for an implementation of runtime-managed lightweight threads.

Edit: I should mention I'm in no way involved in this, just interested in what will come of it over the next few years.

This seemed sparse on JIT updates, I read the linked NEWS page and while it had some feature updates, I'm curious how this is going. I believe JIT went from "likely to speed up most applications significantly" to "may sometimes speed things up, default is off and needs more work."

Anyone know the status of using JIT in something like a rails app?

I believe you’re confusing Ruby with Rails.

While these can eventually come in handy sometimes, they are by and large seldom used, but Rails heavily leverages such patterns for flashy yet ultimately questionable magic.

As a long time Rubyist, I believe Rails, for all its innovation, has been warping the view of what Ruby is, and when and how to use its features responsibly.

Just to clarify for those who might not get it, a new major-ish version of Ruby releases every Christmas.

Anecdotally, since I got away from Ruby, working on software became way more productive and tolerable.

Maybe it was something with the corner of the Ruby world I fell into, but the syntax sugar options and “cleverness” that enabled was maddening to deal with, and permeated that crowd.

Code bases with mixed styles are a thing in any language, but the Ruby-ists around me found a way to make one project look like half a dozen languages were involved.

Insert Confused Jackie Chan meme.