loading...

I'm worried about Ruby future

katafrakt profile image Paweł Świątkowski Originally published at katafrakt.me ・4 min read

Last year at Grill.rb conference Bozhidar Batsov (you may know him as Rubocop creator) gave a talk "Ruby.next", in which he presented his views about current state of Ruby. The landscape was pretty grim: no clear roadmap for Ruby 3, old issues still present, recent changes are insignificant. It is clear that other languages, such as C#, JavaScript or even Java, see more structured development and Ruby is kind of stuck for years.

But the point of the presentation was rather optimistic: we are the community, we are supposed to lead a change and press core team to steer the language development in a direction we want.

Almost a year later, I'm not that optimistic anymore. Let me show you why in 3 examples.

1. Pattern matching

Ruby folks peeking frequently into other languages were bringing up pattern matching topic for some time already. I was one of them. In time, we started to tinker our one solutions as gems. Most notable is probably Qo, but there were others. The point is - there were some existing solutions, some already adopted, on which we could build real pattern matching support in the language itself.

But then suddenly a whole new pattern matching idea appeared in Ruby tracker. And it was merged. And people don't like it, because it is convoluted and cumbersome. For many folks not familiar with pattern matching, it ruined the whole idea, associating the concept with unreadable syntax.

Why was it done this way? Why didn't the core team pick one of existing solutions and build based on that? I don't now the answer, but it smells a lot like NIH syndrome.

I wrote more about new pattern matching here:

2. Pipe operator

Just last week it was brought to community attention that pipe operator has been merged. Sounds pretty exciting, but upon closer examination it turned out that... it does not what pipe operator should do! It's just a syntax sugar for method chaining.

Just to be clear: I'm not against better syntax for things that are already available in Ruby. But picking a syntax that is widely accepted to do something else seems a bit reckless to me. More importantly, it means that probably we are not ever getting real pipe operator because of existence of this half-measure. Whether it's good or not - that's not the point of the discussion. The point is that no one likes this addition and people were supposedly opposing it before merge. That apparently meant nothing, and here we are, we new shiny pipe operator that is not a pipe operator.

3. Frozen string literals

Remember when many years ago the community started to understand that string literals should be immutable by default? They are usually used as keys in hashes etc. and we don't really mutate them that often. Having them as immutable makes it better for memory management, GC etc. And if you actually want a mutable string, it is really easy to make it such.

We agreed that for the time being and backwards compatibility it won't be introduced until Ruby 3. But in the meantime, we widely adopted a magic comment # frozen_string_literals: true as a replacement. The check for comment existence is even "on" in default Rubocop configuration.

Suddenly though in January the core team pulled the plug. Strings are not going to be immutable by default in Ruby 3. We are left with this half-assed comment workaround forever now. Even though the idea was generally accepted by the community.

Summary

Those things make me worry about Ruby future. Even though Matz says otherwise, Ruby does not seem to be a community project at the moment. The core team:

  • comes up with own weird solution instead of re-use what community created
  • adds things nobody likes / needs (apart from them, I guess)
  • silently cancels ideas that were earlier discussed and agreed upon

This is not exactly ideal state for the language that is already lagging behind its competitors. I hope it will change. I hope Ruby 3 has some hidden roadmap and it will be a real breakthrough, not just "oh lol, we were supposed to release it this year, so let's create a tag!". Because this will be a real test if the language is capable to get back on healthy development track.

Or maybe it will stay like it is now forever, with only a minor changes. It's not necessary a bad thing. I'm okay with that. But I would like it to be clearly communicated to the community.


This was originally posted on my personal blog

Discussion

markdown guide
 

I feel like these are valid concerns for the Ruby community. I feel like Ruby isn't going downhill in any meaningful way any time soon but this is definitely all stuff to keep an eye on.

If Ruby goes down hill in the ways you're describing it would likely be a long and slow decline. It seems like things should be okay for a while.

 

Yes, I agree. This is not a call to abandon the ship. I just wanted to express my doubts about leadership in Ruby community.

 

I don't follow what you expect the pipe operator to do. I would expect it to work like a bash pipe that sends the output of the previous command to the input of the next.

 

That's what he meant. That we all wanted it to be.

 

Hmm, I see. I went through the PR in more detail. It appears that it has a lot of strong opinions, some in favor, some in opposition. I think it's a little dramatic to claim the future is bleak for Ruby because there is some disagreement about a minor feature addition. By that measure, Python is clearly on its death bed too.

The author has some very valid points, but I'd spin it the other way and say that the fact the community is advocating for changes means that there are people out there that really care about the language and its frameworks.

 

Ruby should start collaborating together and join forces with Crystal lang.

 

Wasn't everyone excited for JIT?

 

I was in the RailsConf talk about JIT in Ruby 2.7. They've been putting in some serious work to make real improvements. It has some real performance gains in compute intensive code.

 

After ~9 yrs of usage, I'm switching to Node.js.