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.
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
I don't think it has really descoped. They just want the transition to be smooth. So they start slowly. The lead japanese dev will most likely in 2026 go for more extension, and I also think this kind of has to be synced a bit with ractor (I think?).
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
Ractors have promise but the implementations up till now haven't had strong concurrency safety. It seems in the latest release some of the heavy-hitter contributors like Jean Boussier (byroot) have taken a detailed look at Ractors and started to clean things up.
I'm happy if that feature has been descoped because when I last read up on it, it seemed like it was being ramrodded in by an inner circle who were hardly interested in constructive criticism even from other Ruby core maintainers.
I had a similar experience when I asked him what he thought about vars being able to end in a question mark. Very nice guy who probably hears a lot of very bad ideas.
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.
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.)
I'm still a Ruby fan but I share your immense, nearly immeasurable disappointment on the implementation of RBS. It's as though someone was tasked to add types to Ruby but do it specifically in a way that would guarantee zero adoption.
It is 4.0.0 largely because matz created ruby 30 years ago.
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.
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.
Ignoring DHH's politics (which are enough to make me look for alternatives), he makes breaking technical decisions to tooling with little to no community involvement. E.g., https://github.com/hotwired/turbo/pull/971
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.
The Ruby "community" has long been dogged by politics and culture war stuff. This comment[0] on a flagged submission has lots of links for getting up to speed.
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.
Anyone who won't discriminate against others for their politics would be an improvement, because that's not what's been happening in many core projects.
I am not suggesting Jeremy Evans simply because of politics. I think he's very underrated in the community and the work he does is incredible. Having interacted with him a number of times, he's been really helpful and pleasant. I think those qualities make him a good candidate.
I agree. He has scolded me before though, for submitting code he didn't like the look of. Felt a tad harsh at the time, that's the kind of thing that puts people off contributing. However, he's a better programmer than me so if he didn't like it he's probably right. Could improve his bedside manner a bit though. I'm sure others have said that about me too, perhaps I'm a hypocrite.
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.
If programming is just my hobby, then maybe. But would you, for example, quit your current job and look for another, just to change the programming language? I know I'm not that sort of person.
I think it's not as much "if this guy becomes the lead I'm immediately quitting my Ruby job to return to PHP" as much as "if this guy becomes the lead I'm probably going to return to PHP for my next job."
I have my doubts, even for this softer version. These are things where one might feel very strongly in a moment, or even for a longer time, but facing a real life decision, there are so many other factors.
Of course we will never know the outcome of this, it's just my two cents.
I'm tasked to amend a project written in ruby. With a python background (and some nice pydantic, type annotated, etc "strong" code bases behind my back), every day I spend with ruby is a minefield, a nightmare.
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.
> 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 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’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.
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.
Because it's just generic complaining on a random Ruby post. It's just boring language flamewar bollocks that we can have on every post on every language.
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:
I actually love it for small scripts (not more than a couple hundred lines), including small web services and such. Much more pleasant than Python (though Python handles growing beyond a couple hundred lines way better than Ruby does)
I really like a few of its smaller libraries. Just not Rails.
if you just need to write a few hundred lines of code to automate something ad hoc, or play with an idea, or do something exploratory like reverse engineering a file format, ruby is a truly gorgeous language. it just hasn't added the affordances you need to maintain a large code base, which is sad because python has shown that you really don't need that many of them - type annotations and explicit exports that act as namespaces would go a long way.
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.
Any particular changes of interest?
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
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
I don't think it has really descoped. They just want the transition to be smooth. So they start slowly. The lead japanese dev will most likely in 2026 go for more extension, and I also think this kind of has to be synced a bit with ractor (I think?).
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
Ractors have promise but the implementations up till now haven't had strong concurrency safety. It seems in the latest release some of the heavy-hitter contributors like Jean Boussier (byroot) have taken a detailed look at Ractors and started to clean things up.
https://byroot.github.io/ruby/performance/2025/05/24/unlocki...
Isn't everything loaded into the global namespace in Javascript as well? I'm talking about named imports.
I'm happy if that feature has been descoped because when I last read up on it, it seemed like it was being ramrodded in by an inner circle who were hardly interested in constructive criticism even from other Ruby core maintainers.
I had a talk with Matz 1-on-1 about 6 months back and expressed my doubts about namespaces :) He's a nice guy, he just smiled.
I had a similar experience when I asked him what he thought about vars being able to end in a question mark. Very nice guy who probably hears a lot of very bad ideas.
I didn't know Ruby has three different JITs
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.
Nothing about Fibres and Async from Samuel Williams ?
Very little happened in Ruby since 3.2 or even 3, it feels stagnated. Still a very beautiful language from my point of view, but yeah, stagnation.
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.
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.
I'm still a Ruby fan but I share your immense, nearly immeasurable disappointment on the implementation of RBS. It's as though someone was tasked to add types to Ruby but do it specifically in a way that would guarantee zero adoption.
Out of curiosity, why was RBS so poorly executed and adopted?
It is 4.0.0 largely because matz created ruby 30 years ago.
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.
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?
Ignoring DHH's politics (which are enough to make me look for alternatives), he makes breaking technical decisions to tooling with little to no community involvement. E.g., https://github.com/hotwired/turbo/pull/971
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.
The Ruby "community" has long been dogged by politics and culture war stuff. This comment[0] on a flagged submission has lots of links for getting up to speed.
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.
[0] https://news.ycombinator.com/item?id=45379652
I'd much prefer Jeremy Evans[0] taking over rather than DHH. Jeremy is a Ruby core committer (and much more pleasant person), unlike DHH.
[0] - https://github.com/jeremyevans
Anyone who won't discriminate against others for their politics would be an improvement, because that's not what's been happening in many core projects.
I am not suggesting Jeremy Evans simply because of politics. I think he's very underrated in the community and the work he does is incredible. Having interacted with him a number of times, he's been really helpful and pleasant. I think those qualities make him a good candidate.
Fun fact: Jeremy won the Ruby Prize 2019: https://rubyprize.jp/19_iv-nominees01-2-en.html
I agree. He has scolded me before though, for submitting code he didn't like the look of. Felt a tad harsh at the time, that's the kind of thing that puts people off contributing. However, he's a better programmer than me so if he didn't like it he's probably right. Could improve his bedside manner a bit though. I'm sure others have said that about me too, perhaps I'm a hypocrite.
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.
In every interaction with Evans I have had he has been super nice and welcoming to contributors. Maybe he had a bad day.
> I agree. He has scolded me before though, for submitting code he didn't like the look of.
Heh, do you have a link to the PR?
Curious why this suggestion was downvoted to hell.
I've no idea Jeremy ;-)
That is clearly not Jeremy Evans. Maybe a funny joke if that innocent commenter had not been downvoted to hell.
No idea, Jeremy Evans is a really good coder and a nice person. Also a much more influential voice in the Ruby community than DHH.
Would you keep using a programming language leaded by a racist? I wouldn't
If programming is just my hobby, then maybe. But would you, for example, quit your current job and look for another, just to change the programming language? I know I'm not that sort of person.
I think it's not as much "if this guy becomes the lead I'm immediately quitting my Ruby job to return to PHP" as much as "if this guy becomes the lead I'm probably going to return to PHP for my next job."
I have my doubts, even for this softer version. These are things where one might feel very strongly in a moment, or even for a longer time, but facing a real life decision, there are so many other factors.
Of course we will never know the outcome of this, it's just my two cents.
Ruby is not and has never been led by DHH.
This is exactly why we shouldn't use KKScript either. Plus it has 1-based array indexes.
I'm tasked to amend a project written in ruby. With a python background (and some nice pydantic, type annotated, etc "strong" code bases behind my back), every day I spend with ruby is a minefield, a nightmare.
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.
> 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 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’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.
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.
Because it's just generic complaining on a random Ruby post. It's just boring language flamewar bollocks that we can have on every post on every language.
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.
I actually love it for small scripts (not more than a couple hundred lines), including small web services and such. Much more pleasant than Python (though Python handles growing beyond a couple hundred lines way better than Ruby does)
I really like a few of its smaller libraries. Just not Rails.
if you just need to write a few hundred lines of code to automate something ad hoc, or play with an idea, or do something exploratory like reverse engineering a file format, ruby is a truly gorgeous language. it just hasn't added the affordances you need to maintain a large code base, which is sad because python has shown that you really don't need that many of them - type annotations and explicit exports that act as namespaces would go a long way.
With talk here of Ruby stagnating, has anyone checked out Crystal? I have not but have been curious about it.
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.