Ruby 4.0.0 Preview2
ruby-lang.org
ruby-lang.org
I guess at some later point one will dominate and the others will go sleep mode. Just like in the movie Highlander - there can only be one. (I couldn't name offhand which JIT is the main one right now ... I always think it is from Takashi Kokubun but that may now be outdated. MJIT YJIT ZJIT HUJIT WAJIT WTFJIT GRANDMAJIT - too many JITs.)
https://railsatscale.com/2025-02-12-tiny-jits-for-a-faster-f...
The Ruby Ractor (Actor) interface is now completely changed to use a Ractor::Port class, mirroring IPC (inter-process communication) semantics. Ractors were added in 3.0 as a way to get around the GVL/GIL, but having N number of Ruby interpreters running in a Ruby process which would enable executing on N cores at once. For me, hot take but Ractors don't seem to offer major advantages over plain-ol' copy-on-write (COW) forking.
The one "big" feature was supposed to be namespaces, which apparently have now been renamed to Ruby::Box (https://docs.ruby-lang.org/en/master/box_md.html). From what I can glean from the Ruby issue tracker, it appears this feature has been radically descoped, primarily because it had performance impacts, but also, I think probably there are realistic concerns about fit with the existing ecosystem. Unlike Javascript/Python, Ruby has never used "modules" for code isolation--everything is loaded into the global namespace (the "global dumping ground" as I call it.) Now the Box feature is only enabled with an environment variable RUBY_BOX=1
Ractor is also strange. Do many people use ractors? I rarely see them used in actual ruby code out there. Right now it seems to me as if ractors are used by only ... say ... 1% or fewer of the ruby developers out there. A bit more than refinement users ... :P
https://byroot.github.io/ruby/performance/2025/05/24/unlocki...
https://github.com/ruby/ruby/blob/v4_0_0_preview2/NEWS.md
What is interesting to me is the `Ractor.shareable_proc` changes that solved a bug for a use case I was having. And in general fixes for Ractors make them more appealing to use right now, even though they have not removed the `Experimental` flag from them. They are still missing a built-in concurrency primitive like channels or a lock free queue; I'm curious what they will settle on, Ractor::Port is nice but not enough.
https://docs.ruby-lang.org/en/master/box_md.html
Ruby Box is designed to provide separated spaces in a Ruby process, to isolate applications and libraries.Wish we'd see more action on RBS, perhaps getting Sorbet to core or something. At least having some sort of consensus in the community.
Or even some considerable project in the JIT, dunno!
Python is definitely ahead in types, work on removing the GIL... list is huge.
This is always my biggest complaint about Ruby. Last time I made a fuss about this on HN someone pointed out rbs-inline which might make it into the core rbhs gem itself soon! This would be huge for the Ruby community imo
Much of the Python stuff, is actually about rewriting Python tools into Rust due to its interpreter slowness and no one caring about PyPy, now apparently there is even a PEP to rewrite CPython!
https://discuss.python.org/t/pre-pep-rust-for-cpython/104906
I think I read somewhere that Matz is actually in favour of that but Samuel is holding off for now.
IMO the two languages can be quite complimentary, I've been exploring using Crystal + MRuby to create apps, it's been fun so far.
matz is no longer the youngest - although he does look young, he is already 60 years old. He also said he has a retirement plan, e. g. avoiding a situation such as when Guido quit (or semi-quit) from Python (due to fatigue/frustration; Guido is not 100% retired but he is also not necessarily the solo-design-dev either, so it is a bit of a semi-retirement). So we won't know how long matz will be the lead designer of ruby - and who will succeed. Which may be reason to worry depending on who it would be. Imagine DHH takes over - man, there would be an insta-exodus of people ...
So while this release does not have a lot of content as such, one thing that is quite big, even though right now it is not, is Ruby::Box. There are many who don't understand it. The thing is ... I understand the use cases for it. I was not involved in any way with regards to its design, mind you - that was mostly a japanese-group in design. But there are objective use cases for it.
Many years ago I recall on IRC (we oldschool people used IRC back in the pre-discord stone age) some C# hacker said he won't use ruby because there are no strong namespaces, that is, someone else can just overwrite things and then nothing works. Although I think he was a drama guy, and any "danger" to be minimal, objectively he has had a point, simply because ruby had no strong concept of isolation here. Lateron there came refinements. Now refinements are strange, because while I think the use case makes sense, the syntax is strange. Syntax is one huge reason why I do not use refinements; but also because I try to avoid putting my own modifications all over the place, largely because I'd have to distribute that too, and also because modifying core classes, while that has a use, should not be done excessively, IMO.
Ruby::Box kind of builds on that and makes the refinement use case more generic (eventually; I am aware that right now this is not the case but you need a transition stage. Syntax-wise Ruby::Box is also weird, so hopefully the syntax gets easier too, but I instantly understood the use cases. Many people don't, in particular about 95% who demanded a name change away from Namespace to something else, really don't understand the underlying use case.)
Now - making isolated per-project changes is not the only use case. For instance, ractors could be simplified if you know that there are separate ruby processes; ruby threads probably too. These I consider secondary benefits though (and yes, that may be far in the future, who knows; when python removed its GIL though, it put ruby under pressure, aka shape-up-or-go-extinct mode).
One thing I would complain a lot is that on rubygems.org, before RubyCentral went shopify-controlled-only, that people would occupy namespaces. Such as Configuration. I wanted to have a project called Configuration so I can do Configuration.new or Configuration.parse_this_file(). This is possible of course, but when it comes to distributing code, who owns that toplevel namespace? Normally the one who occupied the name first on rubygems.org, sort of. Via Ruby::Box, it should be possible to have ownerships. This could be strong or weak; weak as a hint, aka "psych is owned by ruby core ownershiper but it can be modified", or strong aka making it immutable. Both have use cases. Could also be both. Having this more organized would be really convenient for developers. I would not have to worry whether anyone else uses that "namespace". And of course we need a way to query this state from within ruby code too aka, say immutable:
"If psych is owned by ruby-core, continue to use it."
psych (for yaml) is not a good example here but you can think of any other namespace where you may only want to consider some gems/projects but not others. (Again, the use case may differ between strong and weak ownership, but the thing is that this is an improvement over the prior status quo.)
There are several additional use cases to be had but I'll stop here. What I find strange is that many people who complain, don't refer to the old issues and discussions. We had discussions before refinements were added. About 80% of the people involved, DON'T EVEN KNOW THESE OLD DISCUSSIONS. Either they have dementia, or these are young ruby users who never were active in the old days. It's very strange.
I am not saying all is perfect about Ruby::Box, in particular syntax-wise I'd like improvements, but many people don't seem to understand the use cases, and this is very very strange.
I just don't think Ruby has this "burning need" to have namespaces/modules/erm... "boxes". So we're likely to end up with sporadic usage of Boxes leading to inconsistent behavior.
Of course we will never know the outcome of this, it's just my two cents.
1. Working for someone, even through a large company, is a much more directly supportive relationship, than using someone's free project. Especially since the project has a lot of large contributors.
2. A company is interchangeable, a skill is much less so. You can do the same, or very similar thing at the next company, but moving to a different language involves a lot of learning, even though both are programming languages.
For these reasons, if talking about a lot of people, I can see many of them leaving a problematic company, and only some of them changing their primary language. I'm sure there's someone out there throwing away two decades of experience for an ideal, but I don't think it's realistic, especially not for 1 problematic blog entry.
Fun fact: Jeremy won the Ruby Prize 2019: https://rubyprize.jp/19_iv-nominees01-2-en.html
Regardless of that, anyone who doesn't discriminate against others for their politics would be an improvement.
Edit: a improvement on the other westerners in the core team who might be touted as the next benevolent dictator, as I doubt that benevolence would maintain.
Heh, do you have a link to the PR?
What would you need it for?
Should we not include the negative ones for one person and the positive ones for another?
If Evans were to purge the politics from contributions to the community, then he would be a fine benevolent dictator, and would manage something Matz has failed with (amongst English speaking contributors, at least). That would probably require purging some of the people (as far as possible), as happened recently. Could he do that?
Maybe they're right, there would be an exodus, I just wonder if other languages' communities will want the trouble. The Japanese Rubyists don't care for a second, a nice by-product of Japanese insularity. Ruby would continue in Japan just fine without westerners, don't worry.
He makes it difficult to trust that, were he in charge of Ruby, he wouldn't just take the reigns and stubbornly do whatever he thinks is technically right for "aesthetics" at the cost of all else.
https://jakelazaroff.com/words/dhh-is-way-worse-than-i-thoug...
Can you read through that and still tell me that you want to see DHH be a part of the community?
First off, calling out the decline in "native Brits" isn't code for "white supremacy"—it's about maintaining the cultural and historical fabric of a nation. London has changed dramatically, and if Copenhagen swapped out two-thirds of its Danes for people from vastly different backgrounds without proper integration, it'd feel alien too. That's not hating on diversity; it's acknowledging that unchecked immigration can erode social cohesion, increase crime (like those grooming gangs he mentions, which were real scandals swept under the rug for fear of "racism" accusations), and strain resources. Data backs this up: the UK has seen spikes in street thefts and integration failures, as even left-leaning figures like the Danish PM admit. Framing this as "demographic replacement" isn't a conspiracy—it's observable reality when birth rates plummet and borders are porous.
As for Tommy Robinson's march, sure, some speakers went overboard, but dismissing the whole thing as "far-right extremism" ignores the thousands of ordinary Brits there waving flags out of patriotism, not hate. They're frustrated with elites who label any pushback against radical Islam or failed multiculturalism as bigotry. DHH calling it "heartwarming" highlights national pride, not endorsement of every wild statement. We've seen this playbook before: smear anyone questioning the status quo as a Nazi to avoid debating the merits.
On the paradox of tolerance—yeah, Popper's idea is that we shouldn't tolerate the intolerant if they threaten open society. But who's really intolerant here? DHH isn't calling for violence or suppression; he's blogging his opinions. The article's author, on the other hand, wants to exile him from the tech community over thought crimes. That's the real danger: canceling people for wrongthink, which chills free speech and innovation. Tech thrives on diverse ideas, not echo chambers.
Absolutely I want DHH in the community. He's the guy who gave us Ruby on Rails, revolutionizing web development and empowering countless creators. His politics don't diminish that legacy, and separating the art from the artist (or coder from the commentator) is how we avoid purity spirals. If we start gatekeeping based on views, half the industry—including plenty of left-leaning folks with their own controversial takes—would be out. Let's debate ideas vigorously, but not purge over them. Tech should be apolitical, not contain ideological litmus tests. But this is my opinion, which I think the majority of the population would likely align with.
- https://lobste.rs/s/fpri94/dhh_problem_2014
I hoped that ruby4 maybe implements stuff that python has, like type annotations or making the damn parens mandatory, but no. Not surprised that python has ten times more developers according to stackoverflow's survey... I can't possibly imagine a collaborative project where other people also have to work on the same code base, and not having any clue what a symbol under the cursor might be.
No type hints. No mandatory requires. No parens, so never know if something is a method or, callable, or variable. Basically IRB is a must for development, because in the editor, I'm blind.
And the ecosystem is just sad. Swagger-rails libraries out there are rookie jokes compared to what python has. At least there is decent GRPC / protobuf integration, so all new services I am writing can be in python. Or any sane language.
Implicit imports (“… which package defined this symbol? Who knows!”), dynamic definitions all over the place (“where’s this defined? Literally nowhere until the program runs!”), all that stuff. It’s awful. I feel blind not being able to answer basic questions about a codebase with grep. And that’s not even considering the lack of static typing.
The 4.0.0 release notes (TFA) are like a joke. Here are the language changes in their entirety:
Language changes: *nil no longer calls nil.to_a
That's it.
I really like a few of its smaller libraries. Just not Rails.
I worked for a company who had kept adding to their Ruby codebase for 10+ years, reaching about 50k files. At that point it becomes an unmanageable mess.
Another thing I don't like about Ruby is how much the community has embraced the Clean Code brand of readability snake oil. It's easy to come by the opinion that any function over 5 lines is a code smell and over 10 lines it's outright bad. I've even heard the view that if-else statements are a code smell and I should always try to replace them with different classes that have the same interface. To be fair, that only happened twice, but that's two more times than I've heard it from users of any other language. I think that the Python community usually strikes a better balance between avoiding excessive function/class length and avoiding excessive indirection.
This also puts me off every time, and I've dealt with people who embrace this a lot as a Ruby programmer. Fortunately, you can ignore them and still enjoy writing Ruby code the way you want.
The forced if/else transformations drive me nuts.
Ruby has had type annotations and typecheckers for quite a while. Unfortunately (IMO) the annotations are not inlinine.
> or making the damn parens mandatory, but no.
A linter/formatter can give the effect of that (and tune it for where it is appropraite) whether or not the language has it, though there are good reasons Ruby does not in general.
> No parens, so never know if something is a method or, callable, or variable.
Method and local variable are the only possibilities (callables are either the value of local variables or the return value of method calls),