Let’s get the elephant out of the room immediately: Python has won the popularity contest.

RubyFlow's platform is a resource for Ruby developers, offering insights into Ruby programming language, Ruby on Rails framework, and Ruby-related tools. Through articles, tutorials, and community discussions, RubyFlow offers insights into building web applications with Ruby and Rails. Developers can learn about Ruby gems, Rails conventions, and best practices in Ruby development to write clean and maintainable code.

Ruby Flow

A personal take arguing that Ruby is the superior language for product builders and SaaS developers, despite Python's dominance in data science and AI. The author makes the case through five points: Ruby's pure object-oriented design, the expressiveness of blocks and DSLs, Rails' cohesive 'omakase' philosophy versus Python's fragmented web ecosystem, Ruby's human-readable syntax, and the craft-focused community culture. Python is acknowledged as the right tool for data science and scripting, but Ruby is championed for developer happiness and code aesthetics.

Ruby vs. Python: Why I Choose Happiness Over Hype

2. The “Block” is the Greatest Feature in Programming

3. The “Omakase” vs. The Glue Factory

Code aesthetics…
Not mine, I hate it so much to be honest.
I have not a single reason to use Ruby/RoR, which is quite niche in 2026, over PHP/Laravel/Symfony, for example.
And outside of RoR, just use Python in this segment. Most programmers have Python installed, but Ruby?
It’s not about hype, it’s just much easier to share code.
Ruby can absolutely be a pleasant language, but that does not make it the superior choice for product builders in 2026. For a CTO, the question is not “is this language elegant?” but “does this choice improve hiring, delivery, maintenance, and ecosystem leverage?” On that front, Ruby is much harder to justify and more expensive too.

The author fails miserably with his bad examples:
This Python code
<pre><code>for user in users:
 email(user)
 log(user)
</code></pre>
is shorter and more intuitive as his Ruby version
<pre><code>users.each do |user|
 email(user)
 log(user)
end
</code></pre>
… mind these strange ||
And he sure wanted to make THE ULTIMATE POINT with
<pre><code>1.day.ago
</code></pre>
which unfortunately does not exist in plain Ruby… it’s a RoR wrapper!
For fuck’s sake… stop writing these stupid “my language is better than yous” articles and just use whatever fits best with your tasks … or you have to use because of the project requirements.

Availability will always win. I love Go but the market dictates what languages take center stage. Ruby might be “better” than Python but the markets have chosen Python.

Counterpoint: These examples work for small three line snippets but do not expand to bigger systems. And I’m not even disagreeing with most of the points made. (Except for the ridiculously misleading point about subtracting a day.)
I’ve been working on a RoR app for the past year and for me it’s a truly miserable experience. The people working on this are experienced and love Ruby and still it’s an unreadable mess. Modules reference functions from all over the place because they know where they get included into. Monkey patching, delegations, dynamic code generation make following the control flow very difficult. Nobody really knows what kind of data they have and it shows, in particular with the symbol vs string situation which is clearly demonstrated by the pervasive use of ActiveSupport’s <code>with_indifferent_access</code>. This “conversation with the data” is more of an interrogation; I have no idea what it is but I’ll beat it with a wrench until it gives me what I want. In the end you have to run the app and figure out what the data looks like and what operations are available. Which is I think very much in the spirit of Smalltalk and Lisp which served as inspiration for Ruby. I guess it comes down to building systems with rigid and “boring” tech with higher confidence that the pieces fit vs. building something “fun” then poking it a while and hope that tests cover everything.

People have to remember that Ruby being more niche doesn’t mean that there’s less money to be made from it. The more niche a programming language is, the more you get paid for working with it