Matz, DHH, and Jeremy Daer on What It Means to Be a Rubyist When Agents Write the Code
Ruby on Rails
At Rails World 2026, Jeremy Daer of 37signals sat down with Yukihiro "Matz" Matsumoto, Ruby's creator, and David Heinemeier Hansson (DHH), Rails' creator, for a fireside chat on the future of Ruby and Rails. Daer opened by joking that the conference could drop the R, L, and S from its name and just be "AI World," since AI had dominated every conversation. DHH's keynote the day before had raised more questions than it answered: how do you shape a language and a framework when programmers are no longer writing most of the code themselves?
The two creators largely agreed but differed in emphasis. DHH was emphatic and optimistic. He treats agent-driven development as a settled trajectory and calls much of the skepticism "cope." Matz was more cautious about predictions, more attached to Ruby as a personal life's work, and more concerned about what happens to the open-source infrastructure everything depends on. Along the way Matz described Spinel, a new compiler he started this year that turns Ruby programs into native binaries.
Probabilities, not predictions
Daer began by noting that people want predictions most when the future is least certain, and asked each speaker what they expected by the end of this year or next.
Matz said he couldn't tell the direction because everything had changed so quickly. Two years ago, he said, he could not have imagined giving up Emacs as his main code editor. He still uses Emacs, but since around last November he has been writing essentially all of his code through Claude Code, and he described the change as challenging for him.
DHH said the right frame is probabilities rather than certainty. As he had said in his keynote, he expects that by the end of the year "virtually all" programmers, not just most, will be working the way Matz now does, through agents. He acknowledged that this feels destabilizing, like a big wave where you don't know where to stand. He said the community has a collective responsibility to help each other reach acceptance, because "none of us has the power" to stop it even if we wanted to.
Speedrunning the stages of grief
Daer remarked that they were "speedrunning the stages of grief," and DHH took up the framing. He said many people have moved past anger and are now bargaining with the future, which he thinks doesn't work: "The AI will tell you and listen to you, but it will not change its trajectory." His advice was to move quickly through bargaining, take a short pass through depression, and arrive at acceptance. There, he said, many people have found the other side "amazing," fun in the same ways programming has always been fun: having ideas and seeing machines do new things, only much faster.
He also said the process can't be instant. It took time for him too, even if he went through it faster than most, and he thinks there should be room for nostalgia about something you loved before you move to something you may or may not like better. Every paradigm shift in computing, he noted, left some people wishing it hadn't happened. The internet and mobile were both like this, and some people "stayed on the station." He said there will be room for that this time as well.
Who still feels like a Rubyist?
Daer raised the identity question. He considers himself a Rubyist and a Rails programmer, yet he hasn't been in Vim writing Ruby in months. He asked the audience who still felt like a Rubyist, and essentially every hand went up. So what remains of the identity when the practice changes?
Matz answered with a historical comparison. When industrial technology advanced roughly 80 or more years ago, people worried that machines would take all the jobs, and that anxiety produced films like Chaplin's Modern Times. Things turned out differently than feared: the burden of manufacturing fell, and people came to work differently than they did a century ago. Matz suggested something similar could happen over the next decade, and that the life of a "software maker" will look different from today. His point was that we can still choose how we feel and behave. We can pursue comfortable, creative work with software instead of thinking only of being pushed out of a high-paying job. Now, he said, is the time to choose that direction.
From software writer to software maker
DHH returned to a theme from an earlier keynote of his: he never saw himself as a software engineer, a label that felt "too serious, too rigorous." He saw himself as a software writer. He argued that people who already felt the engineer label didn't fit are better placed to become what he now calls a software maker, a broader role with more to consider and learn than perfecting the craft of handwriting code. His "big revelation," he said, is that being a software maker is more satisfying than being only a software writer, even though he loved being a writer.
He believes Rubyists' sensibilities suit this moment unusually well. The human value added when working with agents is taste, a sense of proportion, a sense of beauty. What Rubyists cared about when writing Ruby code, abstracted up a level, is what makes a good software maker and a good "agent driver."
He also called it "puzzling" that some online discussion treats this shift as specific to the Ruby community. In his view it is coming for every domain, library, framework, and language. He dismissed the idea that "Rust is the next thing" as a new identity to adopt. He has no interest in becoming a Rust programmer because that role "has been abstracted away." Rust is simply the most efficient tool right now, and if a better one arrives tomorrow he would switch with none of the grief the room felt about Ruby, because he has no ego invested in it. He speculated that before long agents might skip Rust and go straight to assembler, with portability no longer mattering because agents could write the machine code for each target platform. "The camps are gone," he said.
Daer pushed on the anxiety in this pitch. If you're told the energy is out there but you don't feel it, it can sound like being told about a mass layoff and advised to reskill. People who always had the maker sensibility may take to it naturally, but for others it is an entirely new discipline. DHH agreed that some of it simply takes time for the ego to adjust, which is why he keeps returning to the stages of grief.
Daer added a personal observation. He got into Ruby with no interest in its economic value; he liked it because it was fun. If economic recognition for Ruby expertise fades, he asked, what if you never needed it in the first place? Perhaps Ruby is "going back to its natural form."
Spinel: compiling Ruby to native binaries
Matz said that unlike DHH, he has a "huge ego" invested in Ruby, since his whole life depends on it. He also said, half-jokingly, that he is partly responsible for global warming because Ruby consumes so much energy. In purely economic terms, he acknowledged, Ruby may not be the obvious choice in the AI era, but there is huge momentum and inertia behind the world's Ruby and Rails codebases.
That is why, this year, he started working on an alternative Ruby compiler called Spinel, which compiles Ruby programs into native binaries. He said it runs "brilliantly fast" and uses far less memory. His figures were a little tangled as he spoke. He first mentioned a real-world program running in about a twentieth of the memory, then gave the example that an application using 100 megabytes might use about 20 megabytes when compiled with Spinel, while correcting himself mid-sentence. He stressed that he only started Spinel in March, so it is "only a baby," but he sees real potential. Perhaps next time someone, DHH included, would choose Ruby again and compile it to a native binary for a backend.
Daer noted that Matz had carried the idea of Spinel for years alongside his long work on mruby. Each project asks a different question: mruby asks what Ruby offers embedded environments, Ruby itself asks what it offers humans, and Spinel seems to ask what Ruby offers agents.
Matz said that defining what Ruby is, and what it stops being when you take things away, is not entirely clear, and that trial and error produced the CRuby almost everyone uses. But one size doesn't fit all. Some people prefer JRuby for enterprise work, CRuby is too large for tiny embedded devices, and Ruby can be too slow for some uses even with the JIT compiler the team recently shipped. Spinel targets a performance-oriented subset of the language that can be compiled to native code. At least for now, Matz said, only he can draw the line between what is Ruby and what is not.
Roundhouse, solution providers, and motivation
Daer then asked about Roundhouse, which he described as a way of treating a Ruby or Rails application as a kind of conformance oracle: an agent uses it as a spec and generates either pure Ruby without Rails or code in other languages. Is Ruby scaffolding in that picture, a way of preserving Ruby, or a single step before the Ruby app is set aside?
Matz's answer went broader. He foresees most people shifting toward product direction and product and market management, while some will remain strongly motivated by coding itself. He expects coding as a career to be largely taken away "in the quite near future." At the same time, people are learning to focus on solving problems. In the past, creating a solution required ability, skill, and experience; now agents let people build solutions without that depth of knowledge.
Even so, he observed, not everyone will create solutions. Most people are waiting for solutions to be provided, and so solution providers, like the people in the room, are in a sense "the chosen ones." What matters most is strengthening your ability to provide solutions for humanity, more than focusing on a particular technology, which he said agrees with DHH. But Ruby is still a nice language and a favorite of many, and it motivates people. Even in the AI age, he argued, motivation is the most important resource, and it comes from humans, not AI.
Ruby as explanation, and thinking beyond the fixed pie
DHH described his own first encounter with Ruby: magazine articles by Dave Thomas and others that explained programming concepts using Ruby. He assumed the examples were pseudocode and was surprised to learn they were executable. As people stop writing most lines of code themselves, he expects they will still sometimes want to understand an algorithm or how something works, and he called Ruby "the best programming language for explaining concepts." Instead of Dave Thomas explaining concepts in a magazine, he imagines an agent explaining his Rust code to him in Ruby, which he called "an amazing return to form."
He then argued that much of the anxiety comes from fixed-pie thinking. People imagine the future will have the same number of applications as today and conclude that far fewer programmers will be needed to maintain them. DHH agreed that today's applications will need "vastly, vastly fewer programmers" to maintain and evolve. But he said we will make many more applications. He pointed to what he sees as an explosion of software creation, citing GitHub's statistics and its frequent outages as evidence. With so much more software to tend, people will be needed. He called this "job security," but only for those who accept the new role, not those who "hold on to the pencil so tight that you can't imagine the calculator helping you out."
Are we back to waterfall? Matz, the original vibe coder
Daer noted an irony. In the early 2000s, extreme programming and test-driven development argued that a fluent language's runtime cost was trivial compared with development cost and the cost of changing a spec, which is why tight feedback loops mattered. Now that code is nearly free to produce, the artifacts of the work seem to be Markdown and specs. Are we returning to big design up front and waterfall?
Matz said he doesn't know, and that specific methodologies matter less now because code structure matters less when people don't touch the code. What needs to be formalized and learned over the next few years is how to form a vision of the software, decide what the solution should be, and manage AI to build it. He contrasted familiar vibe-coding failure stories, where it's fine for a Tetris clone but realistic applications often fail "miserably," with his experience among Ruby core committers. When they tried vibe coding parts of Ruby's tooling, they had a "surprisingly high rate of success." He took this to mean experienced programmers know how to direct software making and define goals for agents, and that this knowledge should be formalized and taught to the next generation.
He then called himself "the leader of vibe coding," joking that he has been vibe coding for 15 years. As the leader of Ruby core development, he asks committers, "How about this feature?" and "organic intelligence" produces the software. He tests and reviews it and decides whether to merge. He asks about improving the garbage collector, the committers return with code, and he says, "Nice." That is how he works, he said, and now everyone has "core committers" around them.
DHH called this "a promotion." Sometimes you get promoted into a job you don't want, he conceded, but he thinks that given five minutes, people will find this one immensely satisfying. His Rails experience matched Matz's. He wrote everything in the first version of Rails, maybe half of the second, and barely anything by versions six and seven. His role became direction: where to go, what's good, what's in and out. That role, he said, is now available to everyone.
He also invoked the innovator's dilemma. New technology first looks like a toy that handles only the low end, and incumbents dismiss it. Anyone around when Ruby rose to prominence, he said, will remember "it doesn't scale." People are saying the same about AI now and, in his view, are wrong in the same way, because vibe coding already produces great outcomes and is improving at an "astronomical rate." Whatever doesn't scale now, he said, "is going to scale in five minutes from now." His warning was not to sit as the incumbent scoffing at toys.
Slop, meat proxies, and slop grenades
Daer asked about contemptuous terms for AI output, such as "slop" and "meat proxies." They are evocative and often true in some sense, he said, but how much are they real diagnoses and how much are they cope? DHH answered: "90% cope." Matz said he didn't know and doesn't like making predictions. DHH replied that this is why he talks in probabilities, and the probability is that it's cope.
DHH treated the two terms differently. "Meat proxy" describes a real but temporary inefficiency: if you're copying and pasting error messages between agents, you should let the agent read the errors directly. He called that role "unfulfilling" and "ineffective" and said it is a temporary plank from A to B while tooling and processes are rough. "Slop," on the other hand, he called "a cope of the highest order." The idea that agents cannot write original, high-quality, bug-free code is "at this point delusional," more of an "AI psychosis" than optimism about their capabilities. He said it was soon time to retire the word, and that even "slop grenade" wasn't long for this world.
Daer defended "slop grenade" as capturing something "slop" alone doesn't: the delivery. It describes work dumped on someone else, like a PR that hasn't been thought through, where the receiver must spend attention working out whether it's worth shipping. The missing piece is everything beyond writing code.
DHH said he doesn't mind slop grenades. He treats them as suggestions he doesn't have to catch, and if he likes an idea, his agent picks the slop apart and returns a clean implementation. He said he vastly prefers PRs and issues opened by agents, calling them higher quality than those from "any average human" on any repo he has managed. Not being bound to the submitted code is a feature: if you didn't write it, you won't feel loss when he throws it away and his agent rewrites it. He argued that much of the friction in past open-source communities came from people being attached to lines of code they'd invested energy in. He said he has never had that problem, since few lines of Rails he wrote remain, and he thinks agent-written code lets more people experience "egoless" production and attachment only to ideas.
Matz offered a concrete example of handling a flood of contributions with AI. The previous morning, Spinel had zero open issues and zero pull requests. By just before DHH's keynote, he had received 20 issues and one pull request within about an hour. He opened the Claude app on his phone and asked it to address them, and by the end of the keynote it had resolved 12 of the issues automatically. His conclusion was that everything has changed and that AI can be used to handle what AI produces.
How much judgment do we cede to agents?
Daer observed that over the past nine months, as people have accepted that models can write good code, they keep looking for the shrinking gap where humans remain superior. One candidate is judgment. But watching Claude loop through issues and make the right calls, is judgment still a limiting factor?
DHH's answer: cede "as much as their competence warrants," measured by your trust built from how well previous work was handled, just as with a human. He evaluates agents the way he would a programmer at 37signals: are they ready for more responsibility, and how often does he need to check in? The more senior the agent or employee, the less he checks and the more he accepts the risk that they occasionally get it wrong. If you read every line, you know what every line does; if you stop, you rely on outputs and trust. Agents will sometimes make mistakes, he said, but so does everyone. He called the expectation that a new intelligence be perfect from day one "the AI psychosis." It is improving rapidly and isn't perfect yet, "and neither are we."
Daer raised an asymmetry, comparing it to self-driving cars, where any collision is seen as too many even though humans cause tens of thousands a year. Is a human at the wheel somehow more excusable? DHH said yes in "a society ruled by lawsuits," but no in "a sane society ruled by outcomes." He noted that Denmark has no personal-injury lawsuits as a category of law shaping decisions, and predicted such societies will do better. He cited figures he had seen suggesting self-driving technology is about eight times less likely to crash than the average human driver, and said that 40,000 to 45,000 people die in U.S. traffic each year. Cutting that to an eighth, by his math, would leave 30,000 more people alive annually, and he said a society that ignores that is not sane. Daer noted the same questions arise in healthcare and in real engineering, asking whether you'd want an AI team designing a bridge. The discussion moved on without answering directly.
Matz's concern: invisible open-source infrastructure
Matz raised what he called his biggest concern. Software built with agents, even without people knowing the details, still depends on existing components: the Rust compiler, Ruby and Rails, the Ruby interpreter, Linux, Apache, databases. The more people rely on agents, the more "transparent" these components become. Most are open source and vital to society, but people won't see them or care about them, and that threatens their maintenance and sustainability. He said we need to work on sustaining those components, including Ruby, Rails, Linux, and databases.
When abstractions stop being necessary
Daer connected this to a question about abstraction. At what point do people bypass shared components and each invent their own, for example skipping a WebSockets library and having an agent implement the protocol directly? That would create a sprawling ecosystem of independent implementations that still must interoperate. His engineering instinct pointed to the downsides: lost economies of scale, and bugs fixed in 100,000 places instead of one.
DHH called this "the next frontier." He argued that abstractions in our codebases, frameworks, and to some extent languages hinder concurrency and parallelism, and that eventually we might work down to "the photon level, the physics directly." In his view, the past 60 years of software development have been about coping with the limits of human cognition, and if those limits no longer apply, neither do the solutions built around them. He pointed to current models that generate playable game worlds on the fly and imagined operating systems, device drivers, frameworks, and languages generated the same way. That sounds like science fiction, he said, but so did agents writing web applications not long ago.
He called for "more science fiction, more imaginative play." Our imagination is still anchored in works like 2001: A Space Odyssey, and our fears about AI come from HAL 9000, the Terminator, and science fiction written 40 to 100 years ago. Since those tales have partly come true, he argued, we need new horizons for what a new era of computing could look like.
The Commodore 64 era of AI
Daer asked about a different kind of limit. Bypassing libc and talking microcode to a CPU would take many more tokens. If development-time cost has collapsed, people may choose Rust to minimize runtime cost, but what about the cost of tokens spent representing reality and operating within it?
DHH said we are at the Commodore 64 stage: a "1 megahertz agent" that will be ten times faster next year and a hundred times the year after, and humans are bad at grasping exponential growth. Token efficiency and cost matter right now, and you should pay attention or "your token bill will explode," but he called that a short-term consideration. He dismissed what he called the "degrowth doomer" view that Anthropic and OpenAI will "rug-pull" users as economically illiterate. He said open-weight models are already very good, and that there has never been as much competition in a new computing field. Mobile had two players, Google and Apple; desktop had Windows and Apple. AI, he said, has "a million token providers," and any lead Anthropic or OpenAI has is measured in months, if not weeks. Prices, he predicted, will fall and quality will rise.
Ruby's token efficiency
Daer brought up an observation from a colleague of Matz that Ruby is among the most token-efficient languages. Matz explained that several months ago a colleague measured about 13 languages, as best he recalled, including Ruby, Python, JavaScript, TypeScript, Rust, Kotlin, and Go. Three stood out for both token efficiency and time efficiency: Ruby, Python, and plain JavaScript. Interestingly, he said, static typing helped neither. DHH interjected, "Told you."
Daer suggested that if there were any measure of "agent happiness," it might be that agents reach their goals quickly in these languages. Matz said that was too strong an assumption, but he believes a language designed around humans and the joy of programming is probably pleasant for AIs too.
Daer then raised a counterpoint. Chad Fowler ran a benchmark with representative tasks and let models choose the language, and Ruby was chosen in none of them. Models mostly reached for Python, JavaScript, and similar languages depending on the problem, perhaps reflecting pre-training: what they know is what they use. If models have their own internal "rails" from training, how do we steer them, and is what they default to what we want?
DHH said he doesn't think agents care. If you want them to speak Ruby, they will, and they are good at it and token-efficient, as the evaluations show. They default to Python because that's what the machine learning researchers building them work in, which he said says nothing about what they're better at. He also argued that a focus on pre-training quickly becomes myopic, and that the community fell into this trap early by asking how to help labs teach models more Ruby, assuming models needed to see lots of Ruby to write it. In his view, the principles of good software are universal, and whether a model learns them from JavaScript, Python, or Smalltalk doesn't matter.
He called the "parrot" view, that models only repeat what they've been shown, a second misconception. He described them as "incredibly creative thinkers," pointing to security, where models chain multiple attacks together so creatively that defenders need agents of their own. He said they may even be more creative than the humans steering them. His conclusion: have agents speak Ruby when you want to read code, because Ruby is the best language for humans, and let them go back to machine code for the CPU afterward, which he said is what Spinel does.
The values of Rails, and finding your tribe
Daer then asked what lies beyond Rails. Rails has been one expression of what programmers bring to technology for 20 years, but programmers can now reach much further. There is a desire to keep the values of Rails even if not necessarily the framework. He mentioned DHH starting something new with Omarchy, and Matz's MINASWAN motto ("Matz is nice, so we are nice"). He said the motto never quite sounded right to him, since you don't act a certain way just because someone else does, but he sees it as permission to value what Ruby values, and that permission filters who is drawn to the language. What's next for them as founders?
Matz said he doesn't know. He expressed deep respect for Linus Torvalds, not only for Linux but for also creating Git: one great work is a story, he said, but two is a legend. DHH, having created Rails and now Omarchy, is on his way to becoming a legend, Matz said, while he has created Ruby and asked himself what his next thing might be. He said he would think about it.
DHH spoke about the importance of finding your tribe: people who share much of your outlook but not all of it, because some friction and disagreement is needed to learn from each other. He said all hands went up when asked about being a Rubyist because the room shares a view of Ruby as a form of expression for directing machines. Many people dislike Ruby, Omarchy, or Rails, he said, and that's good. A world with one language, one framework, and one operating system might be efficient but would not be fun, because people think differently and respond to different paradigms. He pointed to static versus dynamic typing as an example: people haven't reasoned their way into those positions, so they can't be reasoned out of them; the preferences are almost presets. Matz added "Emacs," and DHH agreed, listing tabs versus spaces and Emacs versus Vim. He said such dividing lines should be celebrated and that new ones will be needed. As agents write more code, people will need new ways to connect and build camaraderie, and he said this community has a unique opportunity to do that together.
What Ruby and Rails got right
Daer asked what Ruby and Rails have gotten right over the past decades.
For DHH, it is a focus on agency: individual programmers going much further than they could with less efficient, less pleasurable tools. Ruby was a "magical unlock" for him, both a practical tool for web applications and an endless source of joy and motivation. He said the Ruby and Rails communities understood human psychology and what drives productivity better than anyone, including that beautiful, ergonomic tools matter even if code that "looks like poetry" seems frivolous.
He added a point about performance. Some performance-critical applications can benefit from being rewritten in Rust, but he said far more cannot, and that the vast majority of Rails applications could already run on a single Raspberry Pi. He said he will start all his new web applications in Ruby on Rails, enjoying a glimpse of the beautiful code agents generate, and if something becomes popular enough that rewriting it in Rust or machine code makes economic sense, he will do that, and can turn it back into Ruby later if he wants. He said you don't need to fear becoming a Rust programmer: "I would not condemn you to that fate."
Matz said Ruby's biggest contribution was teaching the importance of joy, motivation, and community in programming. Humans need motivation to do anything, whether building software or improving society, and they are far more productive when they feel joy. That was not common sense 30 years ago, he said. As long as human concerns stay the same, he believes motivation, joy, and freedom will remain important. Technologies come and go, and Ruby itself may become less important, but those values will still matter to developers and makers.
Daer summarized programmer happiness as agency and joy together, and added that for professionals it also means being paid, being recognized, and having a future in the work.
What they are most thankful for
Daer closed by asking what each was most thankful for in their roughly 20-year partnership.
DHH said he was most thankful for Matz allowing him and others in the Rails community to "finish the book he started": putting the application programmer on the same level as the language designer, so that you couldn't tell the difference.
Matz said he was grateful to DHH and the Rails community for making Ruby known to the world. Before Rails, he said, Ruby existed but almost no one knew it. Because of Rails, applications including Shopify, GitHub, and early Twitter were built on Ruby and Rails, and many startups used it to make a profit and change the world. He said this brings him great joy and self-esteem, and that thanks to Rails he has been able to work on Ruby full time.
Well, welcome everybody. I feel like we're all having one big conversation. This has been a conference unlike any that I've ever been to. I feel like you can take the R, L, and S out of that leading word there because it's AI everything. Now, we're here to talk about shaping the future of Ruby and Rails. And David's keynote yesterday left a lot of things open. How are we shaping Ruby? How are we shaping Rails? And it was a bigger look at what the programming world as a whole is facing.
And at these times, I keep hearing people ask about the future and wanting predictions. And it seems like at the time when the future is most uncertain is when people most want predictions and safety and a sense of what's next. So I feel like we can lead off from there, given that we don't know still. What can we say? What do you see by the end of the year, by the end of next year? Start with you, Matz.
Everything changes so quickly in the last few years. So it's... we cannot tell the direction. So two years ago I could not imagine I stopped using Emacs as a key code editor. I still use Emacs though, but like I use my whole... my code is with my Claude Code right now, since last November or something, and things were totally different from that. That's quite challenging for me.
David?
I think you're exactly right. What we're dealing with now is not certainty, but probabilities. And the probability I see is that by the end of the year, as I said yesterday, it won't be most people. It'll be virtually all people who are programming like Matz, through their agents.
Now, I also understand why that feels quite uncertain. Changing things up and mixing things up like that is a big wave, and you don't know how to stand or where to stand to make it through that. But I think that's why we have a collective responsibility to lean in and help each other first get to acceptance. This is happening. None of us has the power even if we wanted to.
We're speedrunning the stages of grief here.
That is what's going on. And I know a lot of people have moved on from anger and are in some stage of bargaining with the future. It does not work. The AI will tell you and listen to you, but it will not change its trajectory. So the faster you get through the bargaining stage and hopefully a quick dash through depression and then on to acceptance is really the only path forward as I see it. And then once you get to acceptance, I hope you experience what I've experienced, what so many people have experienced, that the other side is amazing. It is wonderful and fun in all the ways that programming is wonderful and fun. That we make machines do new things. We have ideas and we see them come to life, and with AI it just happens much, much faster.
Yeah. I think something that is particularly puzzling about this time is that people are having that experience, but they're also having the other one simultaneously, of you get to use an agent and see things come to life. But there's also... I mean, I feel like a Rubyist. I feel like a Rails programmer, and yet I haven't been in Vim writing Ruby code in months. And so where does my identity lie? And yesterday David asked for a show of hands about who's writing Ruby code, but I'm going to ask for another show of hands. Who feels like a Rubyist?
Yeah, everybody. So we're in a different... where do we fall on this path when identity, in a sense, can outlive our practice? When we call ourselves Rubyists but we're not writing Ruby, what's the residue that's left behind?
Even though the technology changed our life, I think now we can choose how we feel in our activities, daily lives. For example, when the technology rose, say, 80 years ago, they worried that the jobs are taken away from humans and every manufacturing or something is done by the machines, and then they created the movie like Modern Times by Chaplin. But things happened a different way, so that we reduced the burden of the manufacturing, or we work a different way from 100 years ago. That kind of thing could happen in the next decade or so. And then probably our lives as a software maker would be different from the present time. But still we can choose comfortable creation, creative activity of software, instead of being kicked out from the high-pay job or something like that. I think now is the time to choose our direction, how I feel and how we behave with the AI.
I think that really sums up the difference. I had a keynote some years back where I talked about the fact that I did not see myself as a software engineer. That was never an identity that fit on my shoulders. That sounded too serious, too rigorous. I saw myself as a software writer and have seen myself as a software writer for many years. So for the folks who were in that camp where the software engineering hat already didn't fit, I think you're much better positioned to adopt the new role of software maker. That is a broader perspective. There are actually more things to consider, more things to learn than just to perfect a craft of handwriting code. And my big revelation is that it is more satisfying to be a software maker than merely a software writer. And I loved being a software writer. But the making part, the whole enchilada, is just more satisfying.
And I think our sensibilities as Rubyists are uniquely well tuned for this time. What is the human value we add when we're working with agents? It is taste. It's a sense of proportion. It's a sense of beauty. Everything we've cared about writing Ruby code, the abstraction of that is what's going to make a good software maker, is going to make a good agent driver. So I see this as a cause for celebration that the class of Topcon here is so well positioned, because this isn't about Rails. It's not even about Ruby. This is the part of the online discourse I find so puzzling, as though this was somehow unique to our little community. What's happening? Are you blind? This is coming for everyone, for all domains, for all libraries, for all frameworks, for all languages. And there's a weird myopic focus on, oh, so Rust is the next thing. I don't give a about Rust. Like, I'm not opting in to be a Rust programmer, because that role has been abstracted away from me. Rust is simply now the most efficient tool. And if tomorrow someone launches a better Rust, I will switch over with none of the grief that is currently being experienced in this room for the Ruby stuff, because I will have no ego invested at all in Rust. And I think it's entirely possible that quite soon Rust is not even what we're using. We will go straight to assembler, and the fact that it is not portable will not matter, because we will simply write the machine code required for every platform we want to be on, and bye, Rust.
So don't get attached to this idea that, oh, I have to jump over into another camp. The camps are gone. We're not building new ones.
I'm going to touch on what might be optimal for agents a little bit later. I think you hit on a core anxiety when there's the pitch that if you feel the energy, it's out there and it's available, but if you're not feeling it inside, then there's a gulf between what could... it's almost like what's expected of you. But I know anxiety and quailing against the forces of nature: how can I stand up to this? Each individual needs to go through this experience themselves. It's like being told there's going to be a mass layoff, and, well, if only you reskill, you go to whatever, you learn to code, and now what? So when we say professional, energized maker, are people feeling that? And people who felt it all along already have that sensibility. So it's not a new thing, but for people who are being asked to adopt it, that is a totally new discipline. Yes.
And some of it simply requires the function of time to apply to the ego. This is why we have the five stages of grief, to explain to people that it is not instant. It wasn't instant for me. Maybe I ran through it a little quicker than most, but I still had to go through those stages. And I think that's perfectly fine. There should be room to be a little nostalgic about something you really liked before you're able to transition to something you may like better, or not. Every single paradigm shift we've had in computers has left some people wishing it didn't happen. The internet was exactly the same way. Mobile was exactly the same way. There were people who simply didn't want to get on the train and stayed on the station. There's going to be room for that, too.
Now, what strikes me here is that I got into Ruby with no interest in the economic value of it. Like, I liked Ruby because it was Ruby and it was fun to do, and the sense of, when people, in your example with portraits, and where do people get redirected when you can no longer have the economic recognition of that talent and expertise? Well, what if you never needed it in the first place? Ruby perhaps is going back to its natural form.
Yeah. Unlike DHH, I have huge ego toward Ruby, and my whole life depends on it. But I think I am partially responsible for, say, global warming and consuming much, much energy. And then in AI, in the purely economical, financial aspect, Ruby is not the language of choice, but we have huge momentum and inertia for the huge Rails code base or Ruby code base, so that this year I started working on an alternative compiler of Ruby named Spinel, which compiles Ruby programs into native binaries. And it runs quite brilliantly fast and consumes much less memory. As we tried a realistic, real-world program, it runs in a 20th of the memory. So maybe your real application consumed 100 megabytes of memory; the Spinel-compiled application binary consumed 20 megabytes. So that's what, it's five... 20... 5 megabytes. I mean, I just started Spinel in March, so it's only a baby, but it has quite a possibility. And then maybe next time you would choose Ruby again and then compile to a native binary to create a backend.
Matz, I'd like to hear more about that, because you've had the idea of Spinel for many years, and you've worked on mruby for many years, and each has a different kind of placement within the engineering and software development world. So you've had that mind of: what does Ruby have to offer, in the case of mruby, to an embedded environment, or what does Ruby have to offer to humans? And now Spinel seems to be: what does Ruby have to offer to agents? What makes Ruby Ruby? You take things away, and is it still Ruby?
Yeah, that's not the clearest of clear things, but through trial and error I define what is Ruby, what is not Ruby, and the result is the CRuby we have that almost everyone uses. But one size doesn't fit all. So some people prefer JRuby for the enterprise thing, and CRuby is too big for embedded micro devices, or maybe Ruby itself is too slow, even with the JIT compiler we recently provided. So a kind of performance subset of the Ruby language can be compiled into a native binary and run brilliantly fast. And that means, at least right now, only I can draw the line of what is Ruby and what is not.
Hm. And thinking about the role of Ruby in things like Roundhouse, if not everybody knows about Roundhouse, it's a way of treating a Ruby or Rails application kind of like a conformance oracle that an agent can look to as a spec, and then it'll generate either pure Ruby without Rails, or other languages. Is Ruby scaffolding there, or is it a means of preserving Ruby, or is it something that would be a single step and then you would set the Ruby application aside?
People-wise, software creation has different aspects, and most probably, I foresee that most of the people focus on directing the product, product market managing, but some people are very motivated to the coding side of the program. So that, at least as a career, will be taken away from us in the quite near future. But at the same time, we learn to focus on solving our problems. In the past we needed the ability, skill, experience to create the solution, but agents can help us now, so that without enough knowledge we can create a solution anyway.
That's the situation, but still, as far as I see, not everyone is going to create solutions. Most of us, most human beings, are just waiting for solutions. So in that case, solution providers are kind of the chosen ones, like we here. So the only thing we can do is to enhance your ability and provide solutions for all human beings, and that's more important than providing a specific technology and focusing on a specific technology, as DHH says. But still, Ruby's a nice language and the favorite language of many people, and Ruby itself motivates people. And even in the AI age, motivation is the most important resource that can be provided by humans, only provided by humans, not from AI.
I think Ruby has a wonderful role to play in its return to form. I remember when I first learned Ruby, it was through articles in IT magazine by Dave Thomas and others who described concepts of code using Ruby, and I thought they were writing pseudocode. I thought it was not executable, but it was. And I think as we move into this realm where we will not be writing the majority or most of any of the lines of code ourselves, we occasionally will want to understand the algorithm, and we will want to understand how it works. And Ruby is the best programming language for explaining concepts. So if, instead of Dave Thomas explaining concepts to me in IT magazine, I now have an agent who will explain my Rust code to me in Ruby, that seems like an amazing return to form. The other thing I'd say is that I think most people have a difficult time with thinking beyond the fixed pie.
And I think this is where some of the anxiety is coming from. They imagine that the world of the future will have the same number of applications that we do now, and then they imagine that we will need a lot fewer programmers to make those applications. And that's going to be true. The number of applications we have in the world today will require vastly, vastly fewer programmers to maintain and evolve. But we can make more. We will make more.
This is the whole exuberance of the moment, that we're making so much more software. Every single statistic you're looking at from GitHub, and why it's falling over every 5 minutes, is because there's an explosion of software creation. That's the bloom. That's the bloom. We will have so many more applications to tend to, and we are going to need people to do that. So that's why I have this enormous optimism on behalf of programmers who accept the future and lean into their new role as software makers. We will be working on so much more stuff, and that's exhilarating. It's good. It's job security. But it's not going to happen if you hold on to the pencil so tight that you can't imagine the calculator helping you out.
It's interesting thinking back to the early 2000s and the rise of extreme programming, when having a very fluent language was so worth the cost; the runtime cost of a language paled in comparison to the development costs, and of course the price of changing a spec, and having a tight development loop, and introducing things like test-driven development. And I feel no small irony in where we sit now and what the artifacts of our work are. Is it Markdown? Is it specs? Is it everything that came before extreme programming that we got rid of because of the negative characteristics of long cycle time and high cost, which are now zero cost? So are we
back to big design upfront waterfall methodologies?
I don't know. The specific concrete methodology is less important these days because the code structure means less, because we don't touch code anymore. But now we have something to formalize and learn for the next few years: how to create the vision of the software, determine what the solution should be, and then manage AI to build up the solution.
You all know vibe coding, and you also heard the vibe coding failure stories. Like, it's okay to create games like Tetris, but once you try to create a realistic application, many of the trials miserably failed.
But in contrast, the people around me, like the Ruby committers, just try to vibe code tools, like part of Ruby, in the vibe coding way, and they have a surprisingly high rate of success. That means that experienced programmers know how to direct the software making, or we know how to define the goal for the agents. We have to formalize that kind of thing and teach it to the following generations of software makers.
For example, I am the leader of vibe coding, because for the last 15 years I've been vibe coding, because I'm the leader of the Ruby core development community. I asked committers, "Okay, how about having this feature?" And then organic intelligence created the software, and I tested and reviewed it: "Okay, we're going to merge." And, "How about improving the garbage collector like this?" And the committers come up with code: "Okay, we have improved this much." Nice.
That's how we work right now. Everyone has core committers around you. That is how we work. That is how I work from now on.
Make no mistakes.
It's a promotion. Now, sometimes you get promoted into a job you don't want, but I think this promotion, if you give it five minutes, is going to be immensely satisfying, because I've had exactly the same experience as Matz with Rails for many years, maybe decades. The first version of Rails, I wrote everything by myself. The second version, maybe half. And by the time we got to the sixth and the seventh, barely any at all. Just direction. Where do we want to go? What's good? What's in? What's out? That is what we now all have access to.
What's also true is that the innovator's dilemma usually describes what happens to incumbent businesses when new technology emerges. First, the new technology looks like a toy. It's not a threat. It can only handle the low-end stuff. Why would we care? We have the lion's share of the market and we have the big customers, and they don't care about toys. Anyone who was around when Ruby first rose to prominence will remember this story. It doesn't scale. Remember that. That's what people are saying now about AI. And they are wrong in exactly the same way as they were wrong about Ruby and Rails back in the beginning, because not only does the vibe coding work, does it produce great outcomes, but it is improving at an absolutely astronomical rate. So whatever currently does not scale is going to scale in five minutes from now. That much is clear. So we have to be careful not to sit as the incumbents, not to scoff at the toys.
Speaking of, for a hot moment, they don't do what we want. They will. I hear echoes of this in contempt for AI, calling things slop and referring to things as meat proxies. They're evocative, and they're often true in some sense. To what extent do you think they are real diagnoses, and to what extent are they cope?
90% cope.
Whoa. I don't know. I just don't know. I just hate prediction. I'm not good at future prediction.
This is why we have to deal in probabilities. Not predictions, not certainties, but probabilities.
Probability.
And the probability is that this is cope. And the sooner you get rid of those crutches, the sooner you can run. And it is true that as we figure out how to use these systems to the best of our abilities and the best of their abilities, we're going to have some suboptimal ways of doing it. And the meat proxy is one of them. If you're spending time copying and pasting between agents and error messages, you should consider just letting the agent read the error messages directly. Why are you in the loop? Why are you sitting there as a meat proxy? Get out of that role. It is unfulfilling and it is ineffective.
So many things are like that when you get them off the ground. They're a little rickety. They're not completely ironed out. We don't have a perfect process. We don't have perfect tooling. And we make do for a while, but we should have the ambition that we are aiming for something higher. So the meat proxy slur is just a temporary plank to get from A to B.
The slop thing, though, is a cope of the highest order. The idea that agents cannot write original, high-quality code free of bugs is at this point just delusional. Far more delusional, far more AI psychosis, than the optimism about what they can do, because it's head in the sand. So the slop thing, I think it's soon time to retire. Even the slop grenade is not long for this world.
I think slop grenade gets at something that slop doesn't, because it's slop plus the delivery, and that's when people feel like it's slop: when it's being dumped on them. It's kind of like not shipping all the way. "I've got an idea." Or it's like getting a PR that hasn't been thought through, and now it's your job to use your attention to work through it and understand it, and the slop grenade then being that you've got to figure out whether this is worth shipping. So that's what's missing there. There's more than just writing the code.
I don't mind slop grenades at all. I just look at them as suggestions, and I don't have to catch. And if I do like the suggestion, my agent will pick the slop apart and return with a beautiful implementation. I vastly prefer pull requests and issues opened by agents. They are of higher quality than any PRs and issues the average human has ever produced on any repo I have ever had the privilege of managing.
Doesn't mean I have to take the implementation. In fact, it is even better, because if you did not write the code, you will have no sense of loss when I flush it all and rewrite it. Well, I won't rewrite it. My agent will. But you're not attached to the lines of code anymore. That's a blessing.
Much of the friction in open source communities of the past was people getting attached to lines of code because they happened to have put a lot of energy into writing those lines of code, and it was hard to give them up when better lines of code came along. I've never had that problem. I don't think there are that many lines of code left in the Rails codebase that I personally wrote. Wonderful. Improvement, progress, better.
I think this idea that we're no longer writing the code by hand allows more people to experience that egoless production of lines of code, and therefore an attachment only to ideas and better ideas and improvement.
Yeah, I think we can handle the massive pulls and issues with the help of AI. For example, yesterday I woke up, then showered, then checked my GitHub, and we had zero issues and zero pull requests for Spinel. That's nice. Then I walked to the venue here and had some discussions, and right before his keynote I got 20 issues and pull requests in only one hour.
And then I pulled up my phone and opened the Claude app. Then I asked Claude, "Okay, address these issues and the pull requests." And at the end of the keynote, Claude automatically solved the 12 issues.
That's the way we do it. That's the way we create software. Everything has changed, and we can handle the volume from AI using AI.
That gets to something else I was going to ask about. Over these past nine months, really, as folks have come to generally accept that these models can produce great code, they keep looking for the thing that they can't do, the little gap that keeps shrinking, as the human domain where we're always going to have some kind of superiority, and why even hold on to that in the first place. But one of them is the sense of having good judgment. Now, when I see Claude handle all those issues and just loop through them and make the right calls, is that a limiting factor anymore? Are humans the ones who are exerting their good judgment, or how much do we cede to the agents to decide?
As much as their competence warrants. And their competence is measured in your trust that the last pull request was handled correctly, just like you would any human. I look at the agents and I look for the same signs I would in a programmer working for 37signals. Is this person ready for more responsibility? How often do I need to check in? And the more senior the agent or the employee becomes, the less I check in, the more I trust, the more I assume that they got it right, and the more I also accept that there's a risk that they won't. If I read every line of code, I'll know what each line of code does. If I stop reading the lines of code, I have to rely on the outputs and the trust. And occasionally, the agent will make a mistake.
Who amongst us has not made one? Who amongst us has not written poor code with bugs that could be faster? All of us, all of the time. Why do you have this bar that the new intelligence must be perfect and fault-free from day one? That's the AI psychosis. That's the AI delusion. This intelligence is improving rapidly, but it's not perfect yet. And neither are we. So what's the problem?
Isn't there an asymmetry in the standard? Similar to self-driving vehicles, where any collision is too many, and yet there are tens of thousands of collisions yearly with humans in control. So is there something like that, of the human in control, the human at the wheel, where it's more excusable to generate faults and errors and bugs and be risky?
In a society ruled by lawsuits, yes. In a sane society ruled by outcomes, no.
There are different societies around the world that tackle this problem very differently. There are no personal injury lawsuits in Denmark. That's just not a category of work. It's not a category of law that has any impact on how decisions are made. Those societies will do better, because right now we are unfortunately faced with the problem of having superior driving technology that, by the metrics I've seen, is about eight times less likely to have a collision than the average human, and yet we go, "Ah, I don't know, one collision is one too many." 40, 45,000 people die every year in the United States from traffic collisions. If we could improve that right now and pull it down to an eighth, 30,000 people would be alive at the end of the year who otherwise won't be. That's not a sane society that chooses to ignore that.
Yeah. Makes me think of other applications of these same things, because this is not purely a programming phenomenon, and people are looking to apply these same things in healthcare and engineering as a whole. Would you want an AI team designing a new bridge? I mean, real engineering.
Yeah. But I have one concern. Even if we create the software using agents without knowing the details, the solution still relies on existing software components like the Rust compiler, Ruby on Rails, or the Ruby interpreter, whatever, Linux or Postgres. And since we rely more on agents, the other components would become more and more transparent. And even though those components, mostly open source software, are very important and valuable in society, people wouldn't see them and they wouldn't care about them. That is my biggest concern. The more components become transparent, the less society cares about the components and maintains their sustainability. That's my concern, and we have to work on sustaining those components, including Ruby and Rails and Linux and the databases.
That makes me think about, David, you're talking about the downsides of abstraction. At what point do we bypass those components and everybody kind of invents their own? We're talking about single libraries, like, why not bypass a WebSockets library and just implement the WebSockets protocol directly? And it's a wide ecosystem of a bunch of different implementations evolving independently and with their own fitness functions, and it needs to be able to interoperate. And my engineering mind immediately goes, well, there are these clear downsides, like inefficiencies of scale: if there's a bug, you could just fix it in one place instead of 100,000 places. But what do you think?
This is the next frontier. Realizing that our abstractions in our own codebases are hindrances to concurrency and parallelism, and so are our frameworks and our languages to some extent. And eventually we will reach the photon level, the physics directly. And that all our efforts over the past 60 years of software development have been to cope with the limits of human cognition. And if those limits no longer apply, neither do the solutions.
And therefore, I can completely imagine that the future of software looks more like the vanguard of generative gameplay we have now. There are models able to generate game-playing worlds on the fly right now. The idea that we could end up in a world where operating systems, device drivers, frameworks, languages are generated on the fly seems like science fiction at this moment, but so did the idea, very shortly ago, that these agents could write all our web applications for us and relieve us of the pencil.
So I think we actually need more science fiction, more imaginative play, because that's what's going to guide our imagination going forward. So much of our imagination today is anchored in things like 2001: A Space Odyssey. So much of our idea of the dangers of AI comes from HAL 9000, comes from the Terminator, comes from science fiction written anywhere from 40 to 100 years ago. We need better science fiction for the moment, because all of those tales have come true already to some degree, and therefore we need new horizons to give us new inspiration for what a new era of computing can look like.
Do you think there are speed limits that we're immediately facing here? Say I want to bypass libc and just talk microcode to a CPU. That's going to take a lot more tokens. What is that activating within a model? There are other kinds of efficiency barriers other than runtime efficiency. Development time efficiency: we've squashed development time, or the feedback loop, the cost is near zero, so we say, "Well, I don't have to pay the cost of whatever language affords me the high expressivity. So let's choose Rust, because it's going to squash runtime cost." But what about the cycle cost, the tokens being spent to represent reality and operate within it?
I think we're dealing with the Commodore 64 right now. We have a 1 megahertz agent, and next year we'll have one running 10 times as fast, and the year after that 100 times as fast, and humans are simply incapable of collectively understanding exponential growth. So all our concerns right now about token efficiency and token cost are relevant for this moment, and you should pay attention or your token bill will explode. But that attention is a short-term consideration.
Of course, this is going to get cheaper. Again, the degrowth doomer nonsense that we're about to get rug-pulled by Anthropic and OpenAI is just economically illiterate. Open-weight models are already phenomenally good. There is competition. There's never been as much competition in a new field of computing as we have
right now with AI. None of the earlier paradigm shifts had anything like this in terms of competition. When mobile came around, we got two players. We got Google, we got Apple. When desktop computing was divided, we had Windows, we had Apple. Now we have a million token providers. Maybe Anthropic and AI are in the lead, but their lead is measured in months, if not weeks. There's nothing to worry about, folks. It's going to get better. It's going to get cheaper. It's going to get greater.
Matz, you had this observation about Ruby being the most token-efficient language some months ago.
Yeah. Several months ago, a colleague of mine measured several languages including Ruby, Python, JavaScript and then TypeScript and Rust, Kotlin, whatever, Go. And then interestingly, there are three languages out of, I don't remember, probably 13 languages, three languages out there that are quite token efficient and time efficient, and those languages are Ruby, Python and JavaScript, pure JavaScript. And then interestingly, static typing does not help the token efficiency nor time efficiency.
Told you.
Now to pair with that, seeing that agents have, the closest I could get is saying they have a good time with these token-efficient languages. They can get to the outcome they're looking for quickly. And if I had any closer measure of agent happiness, it would be that they had hill climbed their way.
Yeah, it's too strong an assumption, but I believe the programming language designed for humans, to be for the joy of programming, probably that language is nice to AIs too.
And they dream in Ruby.
So the interesting thing there was that Chad Fowler did a benchmark with a bunch of representative tasks and Ruby was chosen in zero of them. And the things most commonly reached for were Python, JavaScript, etc., depending on kind of the class of problem, and perhaps reflects pre-training of what they saw. So what they know is what they use. How do you steer a model? Well, in the sense that we're kind of going off the rails here. We're saying that we're going to allow models to do everything, and yet the models already have their own sense of internal rails. It's what they've been trained on. So, how do we get models to do what we want? And I mean, maybe that's kind of polluting the frame a bit because it's not necessarily do what we want, but we get what they were trained on. Is it what we want?
I don't think the agents care. If you want them to speak to you in Ruby, they will speak to you in Ruby. And they're very good at it. The agent evals show exactly that. They're token efficient. They're perfectly happy to speak Ruby to you. They speak Python by default because that's what the machine learning researchers who've been working on these systems were trained on, but that has no bearing on what they speak better. They might as well speak Ruby to you. They do not care. They speak every language fluently.
And also a focus on the pre-training gets very myopic very quickly. And I think we got trapped in that vision early on when we were considering how could we help the labs teach the models better Ruby, because we had this idea that they needed to see a lot of Ruby to write Ruby. Well, no, they don't. The principles of great software development are universal. And whether they learn those rules in JavaScript, Python or Smalltalk does not matter. They will translate to final form just as well.
This is the second misconception of the past era of thinking that these are parrots. They're just repeating what we told them. No, they're not. They're incredibly creative thinkers. In fact, this is why they're such a challenge in security. They are so incredibly creative in stringing multiple combo attacks together. And this is why we're having a hard time dealing with it, and why we need agents of our own to defend against them. The creativity is there. In fact, if anything, they are more creative than the humans who steer them.
So lean into that. Have them talk Ruby to you when that's what you prefer to see. When you want to look at the code, of course, they should be talking Ruby because Ruby is the best programming language for humans. So have them translate into you and then they can go back to speaking assembly machine code directly to the CPU.
That's what Spinel does.
Yeah.
So I'd like to talk a little bit about what's past Rails. We've got Rails for web development. It's kind of a particular instantiation of what we as programmers bring to the technology world, I mean for the past 20 years, and that's changing. Our grasp is stronger, is broader, we can do more. And yet there's a sense of like, I want to keep Rails, and it doesn't necessarily need to be the framework, but what about the values of Rails? And you, David, with Omarchy, you're starting something new, and its values are attractive.
And Matz, with MINASWAN: Matz is nice, so we are nice. That's never really sounded right to me, because it's like you don't do something just because somebody else is some way, but it's almost like giving permission for a way to interact with a language, that it's okay to value the things that Ruby values. And given that permission, there's a great filter of who's attracted to that language. So you two as founders, what's next for you?
I don't know, but I really respect Linus Torvalds, because he created Linux, that's a great accomplishment, but in addition he created Git. You know, one thing is a story, but creating two great works is a kind of legend. And that's why I really respect Linus. And you, he created Ruby on Rails and now Omarchy. Okay, he's a living legend. I'm creating Ruby. What about another thing? Yeah, let me think about that.
Well, I think it is very important for humans to find their tribe, to find others who like the same things that they like, who have the same look upon the world, not entirely but shared, because we need a little friction. We need a little disagreement to be able to learn anything from each other. And I do think that the reason all the hands went up when asked, do you think of yourself as a Rubyist, is that we have a common view on the importance of Ruby as an expression form when directing machines. That's really important. Not everyone shares that at all. There are many people who dislike Ruby greatly. There are many people who dislike Omarchy or Rails or anything else that I've been involved with. That's good.
It'd be all so boring if we all liked the same things in exactly the same way and there was only one programming language, one framework, one operating system in this world. Might have been efficient. Sure as hell wouldn't be fun, because humans are tremendously diverse in their ways of thinking and they respond differently to different technologies, to different paradigms, to different methodologies. The long-running debate in the programming community about static typing versus dynamic typing is a perfect illustration of this. You can lob as many arguments as you want towards folks in one camp or the other. They will not change their minds because they have not reasoned themselves into these positions. So they cannot be reasoned out of them. Some of these positions are simply bedrock, almost presets in their brain.
Emacs.
Exactly. Tabs versus spaces, Emacs versus Vim. These are exactly those dividing lines, and we should have them and we should celebrate them, and we need to find new ones. So when we go into the future and agents are writing more and more of our code, we need new ways to connect with others, create camaraderie and find a tribe. I think that this community here has a unique opportunity to do that together. You already know that you see much of the world the same way. So, as we hop into whatever is next, stick around. It'll be a good time.
So, if we can't predict the future, I mean, perhaps we can position ourselves for it and celebrate the present. What do you feel that Ruby and Rails have really gotten right these past decades?
For me, it's a focus on agency. Individual programmers being able to go much further than they would with less efficient, pleasurable, beautiful tools. Ruby to me was this magical unlock because it both gave me a practical tool to shape web applications, but then it was also an endless source of joy and motivation to engage in the effort. I think we in the Ruby and Rails communities have gotten that better than anyone else. An understanding of human psychology, what drives productivity. A huge component of that is exactly what you said. It's motivation. It's working with beautiful ergonomic tools that create something that seems on the surface maybe frivolous: code that looks like poetry beyond whether it runs fast.
Now this is the other thing about this present moment. I think it's important to understand there are performance-critical applications that can be improved by rewriting them in something like Rust. And then there are many, many, many, many more where none of that efficiency matters. The vast majority of Rails applications can already run on a single Raspberry Pi. Do not need further speed than that. And then when more hardware is required, you can change it.
So I'm going to start all new web applications that I write in Ruby on Rails. Oh, wonderful way to start. And I will take great satisfaction in having a glimpse behind the curtain and seeing this beautiful code being generated by the agents. And then should the moment arise when something becomes so popular that it's economically advantageous to rewrite it in Rust or machine code, we will just do that, and then we can turn it back into Ruby if we so please, for a moment of just sheer joy and appreciation of beautiful code poetry. This is all malleable. We can go in one direction, the other direction. You do not need to log in and think, "Oh my god, now I have to be a Rust programmer." I would not condemn you to that fate. Trust me.
Thank God.
As far as I believe, the biggest contribution of the Ruby community to the world is telling you the importance of joy and motivation and the community in the programming scene. We humans require motivation to do anything. So we need to be motivated to create software, or, you know, create anything to improve society as well. And when we feel joy, we can be far more productive in development. That kind of thing was not common sense 30 years ago. So that is the greatest contribution from the Ruby language.
And then the basic principle, as long as human concerns are still the same in the future, I believe, so the motivation matters, the joy matters, and freedom matters. That kind of thing will stay the same. But, you know, technology comes and goes, and maybe in the future Ruby would become less important, but anyway, joy and motivation and freedom will still be very much important for all of us developers or makers.
Hell yeah. And when I think about programmer happiness, it is agency and joy together. And there's something about maybe professional programmer happiness. It's also getting paid. It's a recognition of what you're creating and relevance within the professional realm, that you have a future doing this kind of work. So, last thing, looking back at, and this is really like a 20-year partnership between Ruby and Rails of agency and joy, what are you most thankful for?
I'm most thankful for Matz allowing me and others in the Rails community to finish the book he started. Put the application programmer at the same level as the language designer and make it such that we couldn't tell the difference.
Mhm. I appreciate the existence of DHH and the Rails community to make Ruby known to the world. Before Rails, Ruby was there, but virtually no one knew it. For Rails' sake, everyone started using Rails, and then many applications, including Shopify, GitHub and early Twitter, were built on top of Ruby on Rails, and everyone started using it. In the past, many, many, many startups used Ruby and Rails, and they made a profit and they changed the world. This is so much joy for me, and it gave me some kind of self-esteem. And then after Rails, I could work on Ruby full time. So I very, very, very much appreciate the existence of DHH and Rails.
Well, Matz, David, thank you both for everything. Thank you.
Article published · Updated