RubyConf 2026 Recap

It’s been a few weeks since RubyConf 2026, and I want to talk about my experience.

Foreword

The past year has been rather tumultuous for the Ruby community, and it seems like rough weather remains on the horizon. Despite spending over 22 years in this community — a community which changed my life by making it possible for me to be a first-generation professional and escape the cycle of poverty — it might soon come to a close due to one loud dickhead and several poorly thought-out decisions. I sincerely hope it doesn’t. The representation and community I felt so strongly in 2004 is still around, but it’s less apparent today than it was back then.

I spent RubyConf 2026 trying my hardest to help Ruby retain the reputation that its community is approachable, whimsical, and full of wonderful eccentric people who are excited to share their love of the language with anyone who shows up. I, of course, did this by being myself. Rather, by being more myself than I have ever been. This was the first professional conference I have attended since transitioning, and I felt just as at home as I have always felt about the Ruby community. It’s no small feat to maintain such an environment across two decades.

If you’re part of the Ruby community, I hope you realize just how precious the community is, and that we are precipitously close to losing it if we continue to focus on the guy with the bad opinions and not those who are actually representative of our community. There is a new “killer app” for Ruby. We should really just let the previous one and its creator die in irrelevance. In other words: Thank You, Next.

The RubyConf program this year was full of interesting talks from people who represent our community the most, and I think that Ruby Central did a good job selecting speakers for RubyConf 2026. The talks that resonated with me addressed new frontiers and challenged old habits. And of course, nothing beats the RubyConf hallway track.

Keeping Ruby Weird

As I said in the post advertising my talk, I was going to do my talk “in character”. What the organizers knew but you probably didn’t was that meant I was going to do my talk while wearing my Ziggy the Hamster fursuit. I had a lot of fun with it and I hope it was a fun surprise for everyone else in attendance as well.

If you’ve never given a talk wearing a fursuit — this was probably my 5th time — let me tell you… it’s an unparalleled experience. I use a Shure PGA31-TQG microphone inside the all-foam head, so it’s just about like I am wearing a portable recording studio. I have pretty good visibility, so I didn’t have much trouble reading my slides, though I did need to split my notes from some slides into duplicate slides to make it easier.

What didn’t quite work was that I had a bit of trouble with my foot pedal. Brandon did, too, in Red in Fantasyland, so I’m at least in good company. I think I’m going to look for a device I can squeeze with my paw instead. We’ll see how well it goes when I try it at BLFC in October.

Besides the talk, I also attended much of RubyConf “in character”. I took a ton of selfies with folks and had a great time doing it. Hopefully, they let me do it again in the future. To my knowledge, I’m the first person to wear a fursuit to RubyConf, let alone give a talk in one at RubyConf, and I’m one of only a few people to give a talk professionally in a fursuit anywhere. Whether this was a good idea or not remains to be seen, but if I made even one person feel like they belong in the Ruby community, I accomplished my goal. Nevermind that it’s a lot easier to deal with the stresses of public speaking as an autistic person when doing it in a fursuit.

I forgot how much I enjoyed hack days

I haven’t participated in a hack day in several years, and I forgot how much I enjoyed it. I got around to the hack day kind of late, so I was able to basically just get a build environment for Ruby Events going (and opened a PR to add some missing documentation because my build environment was nonexistent).

I did get to spend a bunch of time working on Garnet.js, though. I was unable to attend Cameron’s talk because it conflicted with mine, but he explained the gist of it to me. It’s a combination alternative Ruby runtime and compiler learning environment, taking the form of a TypeScript implementation of Ruby. Much of the hard work has already been done with Prism, which is run inside the execution environment as a WASM module. The rest of the work is to implement missing Ruby functionality in TypeScript.

Garnet.js is largely a toy implementation, but it is rather interesting considering that the only comparable Ruby runtime is Opal, and Opal is basically a transpiler rather than a runtime. It makes me wonder whether doing something crazy like taking the Garnet.js idea and porting it to Erlang would be worth doing. There would need to be a WASM interpreter in Erlang (or Elixir) though, and I would have to decide how to model Ruby method calls within BEAM… and I’m not entirely sure it’s worth that considering that it would be hard to otherwise bring the reliability of Erlang/OTP to Ruby. But it’s an idea if someone wants to riff on it.

I plan on continuing to make some contributions to Garnet.js, when I get the time and energy. It’s been way too hot.

I remember magic

One of my favorite talks was Brandon Weaver’s “We Who Remember Magic” (which he also gave as a keynote at Rocky Mountain Ruby 2025). It addresses a lot of the social aspects of how we invite newbies to Ruby in the age of AI, and hit home for me a lot considering that both he and I got into Ruby around the same time, from around the same place, and for around the same reasons. If you were to watch only one talk from RubyConf 2026, I suggest this one.

This talk and the hallway track conversations that followed also convinced me that the best thing we can do regarding the guy with the bad opinions is to maintain inclusive, inviting spaces that have lower barriers to entry than Rails. This includes welcoming new folks whose exposure to Ruby began with an AI coding tool.

Matz taught us a pattern for blocks none of us considered

The Ruby Q&A with Matz was comparable to other conferences. What I hadn’t seen before was Aaron Patterson (aka tenderlove) do comedy with Matz before the Q&A. Most of this part of the talk was focused on identifying the “canonical” style guide for Ruby, as a joke.

It seems like Matz’s style agrees with Standard.rb nearly completely and is very nearly mine. One style choice that came up which left all of us in awe was block syntax. The convention that I have followed my entire career was that one-line blocks were wrapped in {} and multi-line blocks used do/end, like so:

# good
foo.each { |e| puts e }

# good
foo.each do |e|
  puts e
end

# bad
foo.each { |e|
  puts e
}

# bad
foo.each do |e| puts e end

Matz follows this convention:

# good
bars = foo.each { |e|
  e.to_bar
}

# good
bars = foo.each { |e| e.to_bar }

# good
foo.each do |e| puts e end

# good
foo.each do |e|
  puts e
end

# bad
bars = foo.each do |e| e.to_bar end

# bad
bars = foo.each do |e|
  e.to_bar
end

# bad
foo.each { |e| puts e }

# bad
foo.each { |e|
  puts e
}

The pattern isn’t immediately apparent, is it? If you look at Ruby code he has written, going back as far as you are willing to go, you’ll see him seemingly randomly using brace syntax in some places and word syntax in others. So, what’s the pattern? Matz uses braces when a block emits a value and do/end when a block is “void”. When he explained this, the entire ballroom got silent. Not a single one of us had considered doing it this way, and when hearing it explained, had a hard time arguing with the brilliance of it. I’m not sure if RuboCop is going to ever add an option to force this style, but if they did, I welcome it.

Dave Thomas changed some of my opinions about object oriented design

Dave Thomas gave the closing keynote, which was an expanded version of his Stop Abusing Classes article. As I’ve been experimenting in other languages and expanding beyond Rails in Ruby lately, I found myself agreeing with him a lot, even though I’m guilty of many of the things he talked about. The biggest take-away I have from this talk is that classes are supposed to only be object factories, and everything else is supposed to be an object. In Ruby, objects are most easily created as modules, and we should not be afraid of extend self inside a module to make its methods available. extend self also has the benefit of keeping private methods private, vs. module_function that doesn’t. If the original author of the Pickaxe suggests a less common paradigm like extend self, you can probably trust the suggestion.

Using modules this way allows for code that is way more readable. A corollary is that being less afraid of using modules means that you’re less likely to introduce the feature envy code smell. All of this ultimately means you’re writing code that you, your coworkers, and the AI coding agents you’re inevitably going to run on the codebase can work on and understand more easily. This is also the biggest benefit of using Hanami over Rails: everything is explicit, but you’re able to reason about each part of your application in isolation because everything has its proper place.

Conclusion

The biggest thing I picked up at RubyConf was to challenge my beliefs and decide if they still make sense with the benefit of wisdom. Several of them don’t, and I want to turn my subsequent personal growth into some talks so that other people can potentially have an epiphany and continue to do awesome things in Ruby. First on the docket is that I want to give a talk about Hanami at a WNB.rb or SF Ruby meetup, so be on the look out for me posting about it.

Also, apparently Lake Mead is just about empty, and there’s not much left before the dam can’t suck water in anymore. By my count, one tower has 17 sections above water, and only 19 sections in total. I would not run any system this close to its theoretical limit. As best as I can tell, it seems like the plan is to continue government-scale ignorance of Amdahl’s law by making communities conserve water, despite the fact that community water use is only about 10% of total water use. Hopefully we do something different, or we’re going to have a rather harsh FAFO transition.