Ruby is amazing. I recently built a layer on top of Rails that can generate an API from a single markdown file. I did the same thing in python but it was much harder and JavaScript would have been a beast. Ruby can meta program like nothing else.
The ruby::box thing looks pretty interesting, from a cursory glance you can run two simultaneous versions of something like a feature or rollout much more conveniently.
Also being able to do
if condition1
&& condition2
...
end
on multiple lines rather than one - this is pretty nifty too!
Personally && in the new line seems to be much better readability. Can’t wait to use some smart cop to convert all existing multiline ifs in my codebase.
I haven't looked at Ruby for a long time. I've moved away due to the lack of typing. Any degree of typing would be helpful. Does it support typing yet?
_low_type_ is early days still, but I think this approach is clearly the future of ruby typing. If this gets baked into the language for full “compile” time support and minimal performance impact, it will be amazing: https://github.com/low-rb/low_type
There is [RBS](https://sorbet.org/) (part of ruby 3) and [sorbet](https://sorbet.org/). To be honest, these aren't widely used as far as I am aware. I don't know if it is runtime overhead, ergonomics, lack of type checking interest in the ruby community or something else. Type enforcement isn't a big part of ruby, and doesn't seem to be gaining much momentum.
There's an official format for defining types in separate files (RBS) and some tooling to type check them (matz doesn't like types next to the source code).
There's a pretty battle tested tool to define inline types as ruby syntax and type check both statically and at runtime[0].
It's still not a particularly nice situation imvho compared to typescript or python, but there's been some movement, and there's a newsletter that follows static typing developments [1] which may give you some insights.
I’ve used Sorbet on a project for 2 years recently and it honestly was the final nail in the coffin for Ruby for me.
Really rough around the edges, lots of stubs have to be added because support for gems is lackluster but whatever Sorbet generates are hit or miss etc. So you end up writing a lot of hard to understand annotations and/or people get frustrated and try to skip them etc.
Overall a very bad DX, compared to even typed Python. Don’t even want to compare it to TS because then it becomes really unfair.
Python is one the most popular programming languages. Ruby fits into a similar category as Python (high level, interpreted scripting language, very dynamic, has a rich ecosystem with tons of existing code). Being faster than Python makes it more attractive to use, or port Python codebases to.
I'm happy to see v4.0, but 2025 was the year I switched from Ruby to Python after gradually drifting back to it more and more. The tipping point was when I had Claude Code automatically convert one of my Ruby projects to 100% Python - and after that, I just had no Ruby left.
I spent over a decade enjoying Ruby and even wrote a book about it. At this point, though, Python has won for me: fastapi, pytorch, langchain, streamlit, and so on and on.
It's a bit sad, but I'll always remember the Christmas gifts, and the syntax that is always so much better than Python.
To me it seems very few people use ractors. A bit more use fibers though.
It's a bit of a mess IMO. I'd much prefer everything be simplified
aggressively in regards to threads + GIL; and Ractors integrated on
top of Ruby::Box to provide not only namespaced container-like entities
but also thread-support as a first-class citizen at all times. The API
of ractors is weird and really not fun to use.
Right now it is just the foundation I guess. That is, more
work to be put on top of it. byroot kind of pointed that out
that the proposal reminds him of containers and I think this
is the long-term goal eventually, e. g. namespaced isolated
containers. At a later time, I think, the syntax for refinements
may be simplified and also be integrated into Ruby::Box, since
Ruby::Box is kind of a stronger refinement in the long run. But
that's my take; ultimately one has to ask matz about the changes.
What he did say on the bugtracker was that this is to be considered
a low-level API e. g. a foundation work. So things will be put on
top of that eventually.
Ruby is amazing. I recently built a layer on top of Rails that can generate an API from a single markdown file. I did the same thing in python but it was much harder and JavaScript would have been a beast. Ruby can meta program like nothing else.
It's never Christmas without a new ruby version.
The ruby::box thing looks pretty interesting, from a cursory glance you can run two simultaneous versions of something like a feature or rollout much more conveniently.
Also being able to do
on multiple lines rather than one - this is pretty nifty too!I've been doing
for ages and it seems to work find, what am I missing with this new syntax?!Less likely to cause git merge conflict as you don't change the original line. You only add one.
Personally && in the new line seems to be much better readability. Can’t wait to use some smart cop to convert all existing multiline ifs in my codebase.
It wouldn't be Christmas without a new version of Ruby. Thanks Matz and co!
Have they improved tooling? I've yet to get any lsp working on windows
I haven't looked at Ruby for a long time. I've moved away due to the lack of typing. Any degree of typing would be helpful. Does it support typing yet?
_low_type_ is early days still, but I think this approach is clearly the future of ruby typing. If this gets baked into the language for full “compile” time support and minimal performance impact, it will be amazing: https://github.com/low-rb/low_type
There is [RBS](https://sorbet.org/) (part of ruby 3) and [sorbet](https://sorbet.org/). To be honest, these aren't widely used as far as I am aware. I don't know if it is runtime overhead, ergonomics, lack of type checking interest in the ruby community or something else. Type enforcement isn't a big part of ruby, and doesn't seem to be gaining much momentum.
There's an official format for defining types in separate files (RBS) and some tooling to type check them (matz doesn't like types next to the source code).
There's a pretty battle tested tool to define inline types as ruby syntax and type check both statically and at runtime[0].
It's still not a particularly nice situation imvho compared to typescript or python, but there's been some movement, and there's a newsletter that follows static typing developments [1] which may give you some insights.
0: https://sorbet.org/
1: https://newsletters.eremin.eu/posts
I’ve used Sorbet on a project for 2 years recently and it honestly was the final nail in the coffin for Ruby for me.
Really rough around the edges, lots of stubs have to be added because support for gems is lackluster but whatever Sorbet generates are hit or miss etc. So you end up writing a lot of hard to understand annotations and/or people get frustrated and try to skip them etc.
Overall a very bad DX, compared to even typed Python. Don’t even want to compare it to TS because then it becomes really unfair.
We have been adding Sorbet typing to our Rails application and it is a positive enhancement.
It’s not like Ruby becomes Haskell. But it does provide a good deal of additional saftey, less testing, LSP integration is good, and it is gradual.
There is a performance hit but we found it to be quite small and not an issue.
But there are area of our application that use Grape and it is too meta for Sorbet so we don’t try and use it there.
There’s projects trying to implement it. But I’ve never seen a project using typed Ruby.
I think most people who cared just moved to typescript.
Unfortunately, the type support is still useless. I abandoned Ruby for the same reason, and it is still relatively slow and eats a lot of memory.
It's literally faster than Python but ok.
Is being faster than Python considered to be a notable feature?
Python is one the most popular programming languages. Ruby fits into a similar category as Python (high level, interpreted scripting language, very dynamic, has a rich ecosystem with tons of existing code). Being faster than Python makes it more attractive to use, or port Python codebases to.
I'm happy to see v4.0, but 2025 was the year I switched from Ruby to Python after gradually drifting back to it more and more. The tipping point was when I had Claude Code automatically convert one of my Ruby projects to 100% Python - and after that, I just had no Ruby left.
I spent over a decade enjoying Ruby and even wrote a book about it. At this point, though, Python has won for me: fastapi, pytorch, langchain, streamlit, and so on and on.
It's a bit sad, but I'll always remember the Christmas gifts, and the syntax that is always so much better than Python.
You should try Falcon too.
It seems Ractor is still work in progress while Fiber has matured a lot in the last few releases.
I vaguely remember reading Shopify is using Fiber / Rack / Async in their codebase. I am wondering if Rails will get more Fiber usage by default.
To me it seems very few people use ractors. A bit more use fibers though.
It's a bit of a mess IMO. I'd much prefer everything be simplified aggressively in regards to threads + GIL; and Ractors integrated on top of Ruby::Box to provide not only namespaced container-like entities but also thread-support as a first-class citizen at all times. The API of ractors is weird and really not fun to use.
Still love Ruby deeply even though I now work somewhere where it's not in use. Thanks for the release, I hope I find a reason to use it!
My best Christmas gift <3 Love you Ruby.
It truly is Christmas.
Ruby::Box looks useful.
Right now it is just the foundation I guess. That is, more work to be put on top of it. byroot kind of pointed that out that the proposal reminds him of containers and I think this is the long-term goal eventually, e. g. namespaced isolated containers. At a later time, I think, the syntax for refinements may be simplified and also be integrated into Ruby::Box, since Ruby::Box is kind of a stronger refinement in the long run. But that's my take; ultimately one has to ask matz about the changes. What he did say on the bugtracker was that this is to be considered a low-level API e. g. a foundation work. So things will be put on top of that eventually.
This really makes Christmas festive. I don't think I need new features, but sure love simplicity of 4.0.
I am installing it now. Thank you Matz and team.