The NEWS link details a bit more:

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.

Ruby::Box (formally: Namespace)

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.

ZJIT is supposed to be an improvement on YJIT. I'm happy to get any free performance improvements!

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

https://bugs.ruby-lang.org/issues/21311

It actually has several more, if you take into account JRuby + all JVM implementations (OpenJDK based distros, OpenJ9, Azul, PTC,...), ART even if not JVM proper with Ruboto, and TruffleRuby on GraalVM.

I was actually hoping it would be four JITs and we'd get Tenderlove's tiny FFI JIT too.

https://railsatscale.com/2025-02-12-tiny-jits-for-a-faster-f...

Mostly the newer ones try to improve the older ones.

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

Yes, specially ZJIT is news to me.

I was so disappointed in how RBS was executed it caused me to give up on Ruby and move onto something else. I haven't looked back.

If Matz ever retires, I hope it is still maintained by Japanese devs, to keep the insanity that is western politics out of it.

Ruby dev since 2000 and looks like refinements have been available since 2.4. I just used them for the first time this year. Definitely not a go to feature for me, but it was nice the feature was available.

As a practical matter, I don't think DHH is a Ruby internals geek, particularly, and seems to have other hobbies as well, so I don't think that's likely to even be a thing the community faces.

Ruby::Box in its current form seems to radically miss the mark. Any namespace paradigm only has utility if it is widely adopted across the ecosystem. Javascript did this with ES modules 10 years ago--it IS possible--but it takes a ton of buy-in and effort from the community to achieve it.

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.

Curious, why would DHH trigger a mass exodus?

One man's stagnation is another's stability, no?

I checked out crystal. It's a nice little language, but it has a very, very long way to go. IDE support is still quite shaky and the developer community is not large enough yet. There are some few good packages and frameworks that work very well though. I think it's still not supported on Windows as of today.

It has similar syntax, but adding explicit types and macros it's a very different language in practice.

IMO the two languages can be quite complimentary, I've been exploring using Crystal + MRuby to create apps, it's been fun so far.

I used to be a big ruby/rails fan but I have to agree with you. I now write c-sharp and it's a lot less stressful than Ruby. If a Ruby/Rails codebases get to a large enough point it's really difficult to keep track of what types a method you wrote accepts. You end up just constantly double checking your own code. Or you end up with a few type checks and/or type conversions at the top of every method. And maybe I was doing it wrong because it was early on in my career. But when a method can accept literally anything and return literally anything, not even a strong IDE like RubyMine can save you.

> I hoped that ruby4 maybe implements stuff that python has, like type annotations

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),

I’ve sworn off Rails development for anything short of stupid-high compensation for similar reasons.

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.

I don't know. In my experience, the real nightmare is when a competitor uses Rails and has strong developers. Their velocity is insane and I don't see things falling apart when the project gets bigger. Nowadays, I pray that my competitors use something like .NET or Spring Boot. And this comes from someone who never developed in or lead teams that use Rails.

Similar feelings here. Ruby's philosophy of providing a ton of different ways to do the same thing can lead to some pretty sweet-looking code, almost like poetry... but I'd rather have Python's stylistic consistency and better-integrated type hints. Now that Python has Poetry and uv, Ruby's main remaining advantage has evaporated and it's hard for me to justify using the language.

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 is a classic "I am used to language X. I am now trying language Y, but nothing in language Y is like language X! Why can't language Y be like language X?!"-type post. Yes, Ruby is a different language. It does things differently and priorities different aspects.

What's with the downvotes? Every word here is true.

People on HN seem to hate it whenever someone criticizes Ruby. But the language is a sad joke that's gone on for too long. I totally agree with your points and have many more I could mention (lack of proper debugger support and shitty tooling in general - these things exist, but they break every week)

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.