RubyKaigi 2023

I attended RubyKaigi 2023, the annual conference for Rubyists. This year, RubyKaigi was held in Matsumoto, Nagano prefecture in Japan. I attended RubyKaigi last year online, so I'm happy to be there physically.

Matz Keynote

First, we got Matz's keynote. He gave a fascinating talk about the 30-year-history of Ruby with many lessons he learned from. Some of lessons are good name, community to communication, joy can create benefit, marketing is important, people come and go, keep moving forward, leadership and vision, and withstand headwinds.

I was very impressed by Matz's quote from Alan Kay at the end of his keynote, "The best way to predict the future is to invent it." He said that it is possible to create a language that benefits from types without having to write them explicitly. Ruby is sometimes said to have no types, but this is not true. Ruby has types, but they can be inferred from the context. Does it make us more productive to write types explicitly? Or is it even fun? I am glad that Matz is looking to the future and trying to improve Ruby in this way.

Sessions

This year's session focuses on JIT, Parser, and type-related discussions, continuing from last year. However, compared to last year, it seems that there were many other topics presented as well. Among them, I would like to highlight a few memorable sessions.

Power up your REPL life with types

In Ishida-san's session titled Power up your REPL life with types, he demonstrated an implementation that provides a great development experience in which auto-completion in IRB takes type information into account. This demo was quite cool. It was exciting to see the appropriate filtering of auto-completion based on the changing return types through method chaining, considering the types while actually running the code. This implementation has already been released as a Gem called katakata_irb. I highly recommend giving it a try.

After the demo, he explained the detailed implementation of katakata_irb. Originally, IRB relied on regular expressions for features like coloring, but since Ruby's syntax is expressive, regular expressions were insufficient. He explained that he took the strategy of using Ripper to output intelligent auto-completion. In IRB, most of the time, the code is incomplete Ruby syntax, so he took the approach of complementing missing tokens to make it recognized as complete syntax. After that, the system finally obtains information about the target object using RBS and provides auto-completion for method chaining.

I think implementing such a feature is quite challenging, and the approach he took is very informative. It appears that he has also implemented context-aware auto-completion, considering variables, conditionals (such as "if"), and other control flows. It's really cool.

The slides for the session have been published at here.

Revisiting TypeProf - IDE support as a primary feature

In the session Revisiting TypeProf - IDE support as a primary feature, Endo-san gave an overview of TypeProf v2 and showed a demo of the new features. He explained that TypeProf v1 was not widely adopted because it did not significantly improve the developer experience. In response to this, TypeProf v2 is being developed with IDE support as a primary feature. In the demo, Endo-san showed how the type definitions of classes and methods are displayed responsively in VS Code while editing code. This looks very cool and I think it will be very useful. It is expected to be integrated into Ruby 3.3, so I am looking forward to it.

TypeProf displays the type information of a method as taking a String argument if a String is passed to the method as an argument. If a Symbol is passed to the argument in another location, the type information is further updated to define the method as taking a String | Symbol argument. This is a very good feature because it updates the type information responsively according to the usage of the method being edited. However, this can be inconvenient if you want to narrow the type, that is, if you want the method to only take a String argument. In this case, you can specify the type annotation for the method in the code comment. If you pass a Symbol, an error will be displayed. This is a convenient feature.

My thoughts about Ruby tools

There are several type-related tools for Ruby, each with its own purpose. However, users who are not familiar with Ruby may not know which tool to use, when to use it, and how to use it. I think this is a challenge that needs to be addressed in the future.

Nevertheless, the Ruby community has made a great contribution to providing a good development experience. I am very grateful for this. In the future, I would like to contribute to the Ruby community in some way.

Thank you, RubyKaigi.