This is more of a self-reflection than a proper blog post. As someone who has spent the last five years working primarily with statically typed languages and who teaches RBS on Udemy and is writing a book about static typing in the new LLM-powered era, I have always had a complicated relationship with Ruby. Every time I came back to it, the lack of types drove me crazy. The only safety net available was the test suite. Hopefully, you can layer RBS or Sorbet on top, and I strongly believe you should, but that is a topic for another day.

This post is not about static typing per se — it is about where the language is going. Claims that Ruby is slow, dead, and unable to scale have been a constant background noise for years. At 7% popularity in the recent Stack Overflow survey, Ruby is certainly not at its peak, but it is very much alive. The real question is: what will the Ruby world look like in 1, 2, or 3 years from now?

In 2025, JavaScript became the most popular choice for GitHub projects. With frameworks like Angular, React, Next.js, and TypeScript covering the frontend and Node.js, Deno, or Bun covering the backend, you can build a full-stack web application without ever leaving the JavaScript ecosystem. Electron and React Native mean you can even target desktop and mobile with the same language. Throw in the fact that AI is remarkably good at generating JavaScript, and a reasonable question starts to form: do we actually need any other technologies at all?

Well, we are not here because JavaScript is so perfect. The real driver behind the JavaScript monoculture is economics. Engineers are expensive, and maintaining a diverse team of specialists — backend, frontend, mobile, DevOps adds up fast, even for large organizations. A unified stack means a smaller bus factor, a shorter onboarding curve, and fewer technology silos to manage. It is a compelling argument. But that setup has a ceiling. For native apps, web-powered solutions have always lagged behind in UI performance compared to truly native technologies. That gap has existed for years, and the industry learned to live with it or simply to lower its standards. AI is what changes this equation.

You can spin up a new SaaS using Next.js and Tailwind CSS in a matter of days nowadays. But if the idea gains traction, you will have to iterate and improve the product relentlessly, and this is where the drawbacks of a single-technology stack start to show. Some obstacles are manageable — they have been solved before, and the answers are out there. But others are structural and will simply cost too much to work around. In the end, your competitor who chose to ship a fully native app will just have a better product. It will feel more polished, perform more smoothly, and win users on experience alone. Historically, that meant staffing native teams, which was prohibitively expensive for most. With AI, it no longer does. You need a handful of highly experienced engineers and Claude Code or any capable AI agent, and you can cover the full stack — native or otherwise. Microsoft’s recent decision to rewrite web-based apps in Windows 11 using native technologies is a public confirmation of exactly this shift.

What this points to is a return to a healthy zoo of technologies — not because polyglot stacks are fashionable, but because each language was built to excel at something specific, and AI now removes the cost barrier of using the best tool for the job. Ruby, Python, Kotlin, Java, and PHP - each of them has unique strengths that were sidelined in the rush toward homogeneous stacks. That era is ending.

I doubt that Ruby will recapture the mass popularity it enjoyed before client-side rendering with React reshaped the web. That ship has likely sailed. But Ruby will absolutely be used more for what it has always done best: rapid development of web services, whether full-stack or API only. The recent work DHH and the Rails team have put into making Rails 8+ a genuinely one-person framework is not an accident. It is a deliberate bet on exactly the kind of world I am describing.

Here is where things get genuinely interesting for Ruby specifically. It turns out that Ruby is significantly more token-efficient than most other languages. This matters more than you might initially think: AI models charge per token, and the less code they have to read and generate, the faster and cheaper the process becomes. Ruby’s clean, expressive syntax is not just pleasant for humans — it is economical for machines.

But a revival of Ruby in the AI era will also shine a light on the language’s long-standing weaknesses. The lack of types is chief among them. Programming code is not just a sequence of syntactically correct instructions — it is a sequence that makes sense, performs well, and is secure. Generating a set of functions or classes is easy for an LLM; generating code that is correct is the hard part. Without type information, the model has to re-read entire files, re-run tests, and often go in circles when an error is subtle enough to have multiple possible root causes. This is precisely why AI performs better with statically typed languages: LLMs can verify that their changes are consistent with the existing codebase before running a single test.

Here, Ruby is further along than most people realize. Stripe and Shopify — two of the largest and most demanding Rails codebases in the world have been using static typing in production for years. They are not outliers; they are early movers. A typed Ruby codebase gives any LLM a tighter contract to reason against, reducing the number of tokens needed to understand the code and increasing the confidence that a proposed change will actually work.

There is also the question of what you can build with Ruby when it comes to AI integration. Python has decades of dominance in the data science and machine learning space, along with an enormous ecosystem of libraries. Ruby does not have that history, but it has something else. Gems like ruby-openai and ruby_llm give developers a clean, unified API for calling any AI model, and the barrier to building AI-powered web applications with Rails is remarkably low. DSPy.rb takes this a step further by combining AI prompts with types, bringing structure and repeatability to AI interactions in a way that feels distinctly Ruby. For a language built around developer happiness and rapid development, that is a natural fit.

Ruby has always pushed for developer happiness — not in the sense of accommodating every possible use case, but in the sense of making the experience of building software feel genuinely good. In the AI era, that definition is being tested. Happiness used to mean a clean DSL and a forgiving runtime. Going forward, it will also need to mean tooling that helps LLMs work confidently in the codebase, type coverage that catches problems before they reach production, and a framework that a small team or a single developer with a capable AI agent can take from idea to deployed product.

Ruby is not dead. It is not slow. It does scale, and it will perform even better with the upcoming switch to ZJIT. It will not reclaim its mid-2010s glory days — the web has changed too much for that, but it does not need to. It has a clear, defensible niche as a professional choice for building AI-powered web applications quickly and confidently. That is enough, and it is more relevant now than it has been in years.

I will set a reminder to revisit this in 2-3 years and see how the picture has changed. What do you think — where is Ruby heading?