The Origins of Ruby: A Language Designed for Programmer Happiness

When you read about why a programming language was created, the reasons are usually technical. It needed to be faster, or safer, or better at some specific job. Ruby's reason was different and a little radical. Its creator wanted a language that was a pleasure to use, that felt natural to write, and that treated the happiness of the programmer as a design goal worth optimizing for. That sounds soft until you see what it produced: a language so enjoyable to work in that it powered a wave of startups and changed how the whole industry builds web applications.

A language for the programmer, not the computer

Ruby was created by Yukihiro Matsumoto, known universally as Matz, in Japan.^[1] He began work in 1993 and released the first version in 1995. Matz was a language enthusiast who had studied many languages and found that each made him choose between power and comfort. He wanted one that gave him both. His guiding principle was what he called the principle of least surprise^[2]: the language should behave the way a reasonable programmer would expect, so you spend your attention on the problem rather than on the tool.

He pulled ideas from languages he admired. The object model and purity owe a debt to Smalltalk, the text-processing convenience to Perl, and the functional touches to Lisp. The result felt coherent rather than borrowed, because Matz filtered everything through that single question of whether it made the language nicer to use.

Everything is an object

Ruby is thoroughly object-oriented in a way few mainstream languages are. There are no primitive values sitting outside the object system. A number is an object with methods, which is why you can write expressions that read almost like plain description.

3.times { puts "hello" }
[1, 2, 3].map { |n| n * 2 }

Those curly-brace sections are blocks, one of Ruby's signature features. A block is a chunk of behavior you hand to a method, and methods are built to take them. It makes iteration, resource handling, and configuration read cleanly. Combined with the language's willingness to let you reshape classes at runtime, blocks give Ruby an expressive, almost conversational feel that its community came to love.

The framework that made it famous

For its first decade Ruby was admired by a small group, mostly outside the English-speaking world. What changed everything was Ruby on Rails.

In 2004, David Heinemeier Hansson, often called DHH, extracted a web framework from the code behind Basecamp^[3], a product built by the company then known as 37signals. He released it as Ruby on Rails, and it landed like a thunderclap. A famous screencast showed him building a working blog application in about fifteen minutes, far faster than the prevailing approaches of the time. Developers who had never heard of Ruby went looking for it because of Rails.

Convention over configuration

Rails popularized an idea that sounds mundane and was in fact transformative: convention over configuration^[4]. Instead of making you specify every detail of how your application wired together, Rails assumed sensible defaults. Name your things according to the conventions and the framework connected your database tables, your code, and your web routes automatically, with almost no configuration files.

The effect was a dramatic reduction in the ceremony required to build a database-backed web application. Small teams could move at a speed that larger teams using heavier tools could not match. That productivity advantage is a big reason Rails became the default stack for startups in the mid-2000s and 2010s. Twitter, GitHub, Shopify, Airbnb, and many others started on Rails, and the pattern of convention over configuration spread into frameworks in nearly every other language.

The honest trade-offs

Ruby's focus on expressiveness came with a cost in raw speed. For years it was noticeably slower than many of its peers, and critics argued that the productivity gains did not justify the performance hit at large scale. The community took the criticism seriously. A major effort around Ruby 3, released in 2020, set an explicit goal of making the language roughly three times faster than Ruby 2^[5], and work like the YJIT just-in-time compiler delivered meaningful gains. Companies running Ruby at enormous scale, Shopify in particular, invested heavily in making it fast enough for their needs and contributed those improvements back.

What it means today

Ruby is no longer the loud new thing, and that is fine. It runs some of the largest commerce and collaboration platforms on the web, Shopify and GitHub among them, and Rails remains a productive, well-maintained choice for building a product quickly. Developer surveys still show that people who write Ruby tend to like it, which is exactly what Matz was aiming for.

The enduring lesson of Ruby is that optimizing for the programmer's experience is not a luxury. A language that people enjoy using is a language people reach for, build with, and stick with. Matz set out to make programming pleasant, and that pleasant feeling turned out to be a serious competitive advantage.