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 probablyQo, 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 itsmells a lot likeNIH syndrome.

I wrote more about new pattern matching here:

Ruby – Pattern Matching – Second Impressions

Paweł Świątkowski ・ Apr 18 '19

#ruby#patternmatching

2. Pipe operator

Just last week it was brought to community attention thatpipe 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 thatno 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 existenceis even "on" in default Rubocop configuration.

Suddenly though in January the core team pulled the plug. Stringsare 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 onmy personal blog