Running with Ruby

Many of you may not be aware, but Ruby 3 is not only a distant, abstract concept. Ruby 3 is an end goal of a process that is already pretty advanced.

This week I had a chance to participate in a non-public Ruby 3 gathering/hack challenge that was organized by Miles Woodroffe and Cookpad in Bristol.

The goal of events like this one is to gather Ruby core team members as well as many of the prominent Ruby community developers and speakers in one place, to present Ruby 3 work progress, other Ruby improvements, gather feedback, exchange ideas and learn.

People see Ruby as a language that is being developed in separation from the community outside of Japan. It’s hard for me to make an opinion on this, as even with how things are now, it’s not that hard to keep track of all of the changes. However, I do believe, that gatherings like one in Bristol bind the community together, especially since they do connect core Ruby developers with people that are building many of the Ruby ecosystem components.

In this article, I will try to cover for you some of the things that happened as well as some of my opinions on the state of Ruby 2.7 and Ruby 3.

Organization

The event was divided into three main parts:

• Workshops – hacking Ruby 2.7 with all the current development improvements and fixing or reviewing some of them in details
• Presentations – Presentations from Ruby core team members on their recent work related to Ruby future
• Discussions – Open discussions amongst all the guests

Workshops

Did you ever play “Throw & Catch” with Matz? ;)

I didn’t know #rubyhackchallenge was a sport ✨ ⚾🧢 #ruby3 pic.twitter.com/hwMCR5qu9O

— Benoit Benoit (@Benoit_Tgt) 2 lipca 2019

Workshops form was pretty much open. You could pick whether you would prefer to play with the new features or rather spend time discussing selected improvements with core members.

I’ve decided to spend time working on the optimizations of the method #method Method object. I do a lot of #method related pipelined operations in a manner like that:

class TrBase
  def self.call(input)
    data = input.dup
    data[data.keys[0] + to_s] = data.delete(data.keys[0])
    data
  end
end

A = Class.new(TrBase)
B = Class.new(TrBase)
C = Class.new(TrBase)
D = Class.new(TrBase)

stream.each do |data|
  data
    .freeze
    .then(&A.:call)
    .then(&B.:call)
    .then(&C.:call)
    .then(&D.:call)
end

However, not many people know that under the hood, a code as above might create hundreds of thousand objects per second when the data-sets are big enough. I worry that, with a new syntax-sugar, people will use this approach more often, thus sometimes slowing their code a lot just by not understanding what is going on under the hood.

I’ve been working with Koichi-san on introducing internal method cache for the “dot colon” method references. I will write a separate blog post about that soon and explain why in the end it was not merged into Ruby and what we can do to countermeasure that issue.

Apart from that, I’ve been working on dry-monitor with Anton Davydov as it is really rare to be able to meet him and Solnic the same time, in the same place. We did a lot of conceptual work that will allow for shipping some exciting features in the future.

Presentations

There were four presentations:

1. Keynote from Matz
2. Types in Ruby from Yusuke Endoh (Mame)
3. Concurrency improvements and future concurrency models for Ruby by Koichi Sasada’s
4. Compacting GC in Ruby 2.7by Aaron Patterson

“Nothing new” one may say. Many of the things presented were already announced or introduced during various conferences before. What was different is the fact that the core members had way more time to answer questions and to get involved in discussions.

Due to the type of work that I do in Castle, and my OSS I was in particular interested in new concurrency models for Ruby.

Koichi-san presented concepts like Auto-Fibers, Threadlets, Guilds / Isolates as well as ideas on where and when each of them could be used. If at least part of the solution hits Ruby 3.0, we might see significant performance boosts for many things.

Discussions

Here are things that I did consider significant that were discussed:

• Matz is aware of the “pipeline operator problem.”
• Matz calls it a chain operator, and he is considering either changing the syntax or postponing this change at all.
• Matz does not believe that more ways of expressing the same concepts in the language increase its entropy.
• Matz is against deprecating by “gemifying” non-syntax potential incompatibilities (see ERB old and new API).
• Guilds API is not stable; thus, for now, there is no way to mimic that feature with threads.
• Ko1s Guilds API Ruby branch is not workable, and the progress on Guilds is not too fast.
• Global Object Space is a problem for Guilds in the context of memory allocation.
• There is no way to assess memory fragmentation without taking dumps. Noah Gibbs suggested a solution that could allow cheap runtime estimation of that value. However, I did not yet verify his idea.
• Gradual Write Barrier insertion should allow further memory optimizations while maintaining compatibility with the C API.

Summary

It is worth keeping in mind that one of the things that make Ruby a productive tool is the availability of libraries and pre-brewed solutions.

Gatherings like this one allow libraries creators and maintainers to get a bit more insight on current and future development of features and improvements that could be used to build up even more amazing libraries.

At the moment, I’m disappointed only about the fact that Guilds API is not yet ready even as a concept. I do understand the reasons, but having “more or less” frozen API would allow me to mimic it with native threads and make things like Karafka “Guilds ready”™. Without such a piece of information, none of the lib builders knows what to expect. I do fear, that if Guilds are not being presented upfront, we might end up having Ruby 3 with a feature, that won’t be supported by the majority of the main libs for a long time.

After the gathering, I also don’t share Paweł Świątkowski worries that much anymore.

For example, what he calls an NIH syndrome is in my opinion more of a cautious approach towards building things that will have to be maintained for a long time (and knowing Matz approach – probably forever).

There shouldn’t be a single component of the language, that couldn’t be debugged or fixed by at least one of the core members. It applies to things like GC, Memory allocators but also any new stuff like pattern matching. In the end, who would want things that could break Ruby but that couldn’t be fixed fast enough? Same applies to the chain operator (that, in my opinion, is useless).

Is Ruby on a good road to become something more than it is now? Definitely yes, however, it is a bumpy one with many challenges on the horizon.