RubyKaigi 2024

From May 15, 2024, for three days, RubyKaigi 2024 was held in Okinawa, and I participated.

I arrived in Okinawa on May 14. First, I attended an event called Asakusa.rb Welcome Drinkup hosted by ANDPAD. I thought the Asakusa.rb community had a long history, and I was worried if I could fit in. However, I was able to sit at a table with members who were also attending for the first time, and I enjoyed the conversation. At that table, Ruby committer Sasada-san was also seated and was very friendly, which left a strong impression on me. Sasada-san usually works to improve Ruby itself, but out of pure curiosity, he was asking about the members' usual work and how they use Ruby in their daily tasks. I felt lucky because I rarely get the chance to talk to him.

May 15 was Day 1 of RubyKaigi 2024. The keynote by tomoya ishida (@tompng) was very exciting and entertaining. @tompng is the Gold Medalist of TRICK 2022. As you can tell from that, he is very skilled at writing peculiar code. In other words, he is good at writing code as art using things like Quine, and he talked about how such activities of writing weird code eventually lead to discovering bugs in Ruby and improving it, which was very convincing. In the latter half of the keynote, he held a solo TRICK and showed his works. The code was very peculiar, but it was a properly functioning Ruby program, and most of the works turned into animations when executed, greatly enlivening the venue. The peculiar code was not just using Quine but was a well-calculated program using mathematical formulas for animations. It was a very educational content for programmers, and I realized that I have a lot of knowledge to catch up on.

Another memorable session on Day 1 was @spikeolaf's "The grand strategy of Ruby Parser." This session further developed the topic from last year's Lrama about replacing Bison, showing a clear roadmap of the remaining challenges after the replacement. When Lrama development started, there were no other developers involved, but now many developers interested in Lrama have come forward, making the implementation of a universal parser more realistic. @spikeolaf has a lot of knowledge about parsers and tends to speak quickly, but for some reason, the content of the session is well remembered. Even though I am not very familiar with parsers, I could understand the content, making it very easy to follow. It is clear why many developers have come forward since last year because @spikeolaf makes parsers seem very enjoyable. It was a very good session.

Another impressive session on Day 1 was @tagomoris's "Namespace, What and Why." This session was about creating namespaces in Ruby. In Ruby, constants are registered in the global namespace, and defining methods in a class with the same name reopens the class, registering (or overwriting) methods in the original class. This session was about whether it is possible to prepare a truly independent namespace. It is very ambitious, and it is understandable that many users want such a feature. In this session, they demonstrated the namespace under development. Although a backtrace appeared at first, it succeeded on the second run. Seeing such a raw state demo was a valuable experience. It seems to be in the middle of development, so I am looking forward to it. If it becomes available, I would like to try it.

After Day 1 ended, I attended the RubyKaigi 2024 Official Party. It felt like a barbecue by the beach.

On Day 2, the session that left an impression was @soutaro's "Embedding it into Ruby code." This might be controversial, but it is a proposal to allow RBS information to be written in code comments. Not just a proposal, but there is already an implementation. Amazing. The background is that when writing RBS, you have to update both the .rb file and the .rbs file. Sometimes, you need to modify two files for one fix. This is not very desirable for the development experience, so the idea is to write types in the same place as the code. I think the concept itself is not bad, but there is room for discussion on how to write the types. @soutaro himself seems to be considering various ways of notation and was seeking opinions from participants in the following "Ruby Committers and the World" session. Watching @soutaro, I was impressed by how he values feedback from the community rather than just imposing his ideal. This made me realize that Ruby is improved by the voices of the developers who actually use it. Thank you.

After Day 2 ended, I attended a social gathering just like on Day 1. This day, I participated in the Drink up at RIZAP Drinkup at RubyKaigi 2024. It was quite lively. The RIZAP employees were considerate and organized seat changes, giving me the opportunity to talk to various people.

Day 3 started with a session called "Ruby Committers and the World." In this session, all the Ruby committers present at the venue went on stage to discuss several controversial topics and call on the audience for opinions on things under development. For example, they talked about whether to make frozen string literal the default in Ruby 3.4 and about RBS inline. The highlight of this session is that you can feel that the programming language Ruby is "created by people." Of course, all artifacts are created by humans. You can understand that in your head, but it is hard to feel it. However, you can feel it in this session, which is held every year. Just watching this session is enough to fully enjoy RubyKaigi. The charm of this session is that a programming language created by people is discussed in public, and the future is talked about. Perhaps someone inspired by this session will become a future committer. It is a wonderful session.

The keynote on Day 3 of RubyKaigi was Matz's session. The surprise in this session was the decision that if namespaces are realized, the Ruby version could be raised to 4. This feature was considered in the past but was not realized. Other considered features have been mostly implemented, and namespace is the last piece. Such announcements are exciting.

RubyKaigi, as usual, has many talks focused on internal implementation, with more discussions from the creators of Ruby rather than the users. It is unlikely to understand everything perfectly. However, even if you do not understand everything perfectly, it is a wonderful event where you can feel that Ruby is created by people. If someone is attending RubyKaigi for the first time next year, I would advise them to "feel the people rather than try to understand things speakers talk." If you just go, there will be some meetups, and you can talk to someone. If you make acquaintances, you might meet them again in the community in the future. To seize such opportunities, I highly recommend RubyKaigi.

Thank you, RubyKaigi.