Please stop using Ruby

James Harton on September 12, 2018

I know what you're thinking but I want to start by saying that I love Ruby. Ruby is the language that made programming fun again for me after losi... [Read Full]
markdown guide

So...respectfully, I am going to go in on this.

I really feel like we need to slow our roll on shit-talking Ruby on Rails. Very few of us are ever going to have to worry about scale on a level where Ruby‘s raw performance metrics are going to be that impactful. Plus, let us not forget one of the main tenets of Ruby: programmer happiness.

I did not go to school for CS, so I don’t have the acquired taste for FP that a lot of folks have, I guess. I’m a digital carpenter; I want the code to be clear, easy to understand and flexible. Ruby is one of the best for that.

If you really think that you’re going to be managing 1M connections on one node a la Elixir (WhatsApp), go for it. That said, let’s keep the click-baity holier-than-thou hot takes to a minimum.


You don't think there's anything holier-than-thou about idea that Ruby is one of the happiest languages to code in? Is the hardly subtle implication that engineers who care about performance can't possibly care about readability really going in on this respectfully?

What are the metrics for programmer happiness? How did you collect your data? What's your sample size? How can you even begin to honestly substantiate that claim beyond "I like it and everyone who insists on using it despite it's demonstrable problems likes it."

Everyone who insists on writing C# likes it, and people who insist on writing Elm are convinced that functional programming is obviously the most pleasant. Some people still swear by Ada.

Ruby is one language of many that allows you to write readable code.

And while there are languages that make it hard to write readable code; there are zero languages that make it hard to write unreadable code. Ruby doesn't even make writing unreadable code the least bit difficult.

I once was stuck on a rails error for 2 hours because I typed validate instead of validates. Any compiled language's editor would have caught that as soon as I typed it. Ruby was able to spin up the whole app and run indefinitely without ever feeling the need to say "BTW, I don't know what that method is."

Is "Please Stop using Ruby" a click-bait headline? For sure.
Are some of his criticisms of the language valid? Absolutely.
So yeah, this should have definitely been titled something like "Considerations to take into account before starting your next web project as Ruby on Rails"


I never said "Ruby is one of the happiest languages to code in". I said it's primary focus is "developer happiness', which is direct from Matz.

I think the fact that RoR is the de facto on-ramp for most devs coming out of boot camps says a lot for its accessibility. Is Ruby the happiest language? Highly unlikely! People are made happy for all sorts of reasons.

My whole point was addressing the obviously craven title and the nasty habit people have for shitting on other peoples' tools. Write your next app in mindf*ck for all I care. If that's what makes you happy and it does the job, great! The idea, however, well all need these super-concurrent, ultra-fast, functionally-programmed, EVERYTHING-less apps is silly. Very little of what most of us do is a) that serious and b) even going to be around in 5 years.

You’re absolutely right that shitting on people’s tools is bad.

I don’t know that i’m aware of sufficient evidence to agree that “what most of us do is [not serious enough for the performance concerns to matter].” And the claim that what most of us are doing isn’t going to be around in 5 years disagrees with my experience. Anecdotal I know, but a company a worked for until recently still maintains and adds new features to and ASP classic application.

I certainly agree that languages/frameworks persist. I work on a team as the only RoR guy with a bunch of Java developers. We have services in C# all over the place. All the more reason to cease and desist with the "mine is bigger than yours" malarkey.


validate is also a claim method in rails. Your example does not prove your point at all. It just shows you don't know rails well enough. Sorry, couldn't let someone be wrong on the internet. 😂

"I don't know rails well enough" exactly proves my point when the opposing point is "rails is a productive framework and makes developers happy!"


Just here to say that I love your "digital carpenter" phrase! Adopting it ASAP! 😆😆


Please stop using absolutes in article titles. It's condescending and only serves to annoy, infuriate, or (worst of all) repel your prospective reader. 💚


I can relate to your experience, James. I tried moving to other frameworks, even to better option you mentioned.

But rails has one big upside, which is hard to ignore -- maturity of libraries (gems). With a big probability I can find a library that satisfies my picky requirements.

With Phoenix and Elixir I still find myself spending too much time on very trivial things. Since I'm an indie dev -- this is a luxury I can't afford.

But I can afford rewriting some components in languages that performs better, if there is a bottleneck in Ruby itself. But in a lot of cases, I just know how to make Ruby performant :)


Yep, as a one-man-show, it's tough to argue there are a lot of better options that allow for more productivity/hour than RoR.

If I find myself in a situation working on something that has 1mm connections simultaneously, sure, I'll use Elixir. But to spin up a CRUD app, which honestly, are still to this day, most online web apps, Rails and Ruby are tough to beat.


I use my own fake-webframework (created before rails came out).

Granted, it is way below feature parity with rails. But it also does not want to be feature equal.

I also use sinatra so I more belong into this world of simplicity.

And I am mega-productive related to the www there too, without needing RoR (but I value simplicity at all times; I hate the complexity of rails).

I just wonder why people think the www in ruby belongs to rails. I don't see it that way at all.


I agree that Rubygems is one of the main reasons that people stick with Ruby and it is an amazing resource. I've written my fair share of gems over the years and I hope that they helped people in some way. Working with Phoenix can be pretty annoying when you can just get a hex package that just handles user authentication the way that devise does - you have to wire up a lot of code to get it to work. I think this is mostly about maturity but I think it will get there. I once joked that Elixir is powered by thousands of angry Rubyists and like all jokes I think there's more than a grain of truth in it.


Rubygems is great but I do not rely on it.

I can write whatever I need just fine, if I need it.

I wrote my own "package" manager in ruby and have been using that for ~13 years to manage my *nix systems.

I once joked that Elixir is powered by thousands of angry Rubyists

Elixir has great ideas; erlang is awesome, but the syntax of erlang is UTTER SHIT.

But even then, too few people use elixir; and even fewer use crystal.

Say what you want about ruby but ruby IS used by LOTS of people.

I think this is mostly about maturity but I think it will get there.

This depends on how many people use a language. Crystal struggles a lot because of this - too few people go into crystal. Which is a shame. But I myself also am not using crystal, primarily due to lack of time; but also because the type-madness leads to syntactic monsters that I don't want to deal with.

Note that ruby 3.0 will get additional type information, so some of your fake-complaints above may be answered.

I still think your article is horrible though. Please try to make your points more objective in general.


A few points:

  • Rails is adapting to this world that just doesn't ony "shuffle data back and forth" (integrating webpack, adding websocket support). Also stimulus.js by Basecamp goes into that direction

  • Ruby is getting better and better (well it would be funny if it got worse :D): there's talk of adding JIT compilation, guilds (sort of isolated processes in user space) and type decoration

Maybe it won't innovate fast enough and lose developers (it happens to every technology I guess) but there's a valid argument for it you didn't make: there are still tons of Rails jobs :-)

Rails (and Django) are turning into "boring technologies", which is not inherently bad :-)

I'm more optimistic about their future.


My sense of parcel anxiety from yesterday is eased big time from leadership in the Rails community which does a great job of sniffing bullshit in web development and keeping things smooth.

This probably keeps me in Ruby more than anything else.

Although Rust and Elixir and others have a lot of former Rubyists leading the way in DX and pragmatism, as the post implies. Still, Rails makes me feel like I have some serious teammates in the game from small-to-medium-to-big organizations and lots in between. It's such a rock solid boring ecosystem.


This is really great to hear and I am forced to admit that I stopped following along with changes to Ruby a few years ago.

I also agree that "boring" is exactly what you want in production. But boring and slow?


"Fast enough". This is a really good article from an expert in Ruby and Rails: Is Ruby Too Slow For Web-Scale?


It's strange to see someone who benefited so much in their career from using Ruby and RoR turn around and discourage others from using it as well. The reasons you list to not use Ruby lack nuance. For example, you claim Ruby is slow, but what are you comparing it to and in what situation? Yeah, Ruby doesn't take advantage of multiple cores, but that doesn't mean it's useless.
And the reasons you list why someone should use Rails are incredibly backhanded. Saying someone should use Rails if their app never changes or if it doesn't have complicated logic is not apart of a #healthydebate.

And just because a language is faster and compiled that does not guarantee that you will write better software.

The point of rails is that it lets you develop and iterate over a prototype very quickly. This is the reason a lot of successful companies were able to get off the ground and make money relatively fast.
Also, those same companies have used Ruby for very complex systems. An example is Airbnb, who wrote their large scale payment application initially in Rails. While they did migrate to Apache Kafka & Spark, they did it because of the massive increase in users, not because Ruby isn't multi-threaded.

Ruby and RoR were never meant to be the perfect tools but only focusing on their drawbacks isn't enough for telling people to stop using the language. And it's frustrating to see this kind of thinking in 2018.


While I agree with the assumption that we need to watch our website's performance and we should stop deliberately using slow languages (like Python and Ruby) and frameworks, this article missed the chance to point out that the most common problem with slowly loading websites is that they include a few megabytes of JavaScript which needs to be downloaded and parsed first.


The #healthydebate hashtag and this clickbait title doesn't match.


No, I won't. I would only agree that Ruby is not the go to language for everything you do or for everyone / every project.

That being, please weigh your choices with care, use matrices that make sense and avoid noisy opinions you see on web.


So it's basically a long and click baity article about static types > dynamic types? Wow never heard that argument before. Oh yeah and the performance issue, of course. Happens to me everyday at work when I need to sprinkle more performance on my app but alas Ruby fails yet again. If only it was written in java.


Because Ruby's semantics defy almost any kind of static analysis where a user of another language could add a type constraint

I will leave it here:


Looks like Javascript+Flow to me, which is by far not as capable as Typescript. I love Ruby, but typing is a language feature and does not belong into a library. IMHO. Hope Ruby 3.x will come with optional typing.


This will not happen. I saw a quote from Matz that he believes that type signature will be obsolete in 10 years and he doesn't want to add them (I will need time to find it). Important: he didn't say that he against static types (he is for it), he didn't say he against static analysis (he is for it).

The second point, nobody wants to repeat the Python2 vs Python3 situation, so it will be a gradual type system (I guess).

Javascript+Flow to me, which is by far not as capable as Typescript

I'm doing a series of blog posts on Flow and TypeScript. There are, for sure, differences, but not so dramatic. The biggest issue with Flow is closed development, awful tooling and not very big community, but not the power of the type system itself. It is fairly comparable to TypeScript.


I didn't see any reason to stop using ruby in my private automation tasks. Using ruby in the company productions is usually question of managers that keep in mind a lot of reasons that sometimes is not technical related.

  1. GIL does not cause any problem for python to grow up. So why should it be problem for ruby?
  2. Ruby concurrency (don't mess it with multi-threading) actually works pretty well via fibers. This approach is pretty popular in other scripting language. For instance Python has a lot of libs that implements of actor model: Pykka, Thespian. Asyncio is included in stdlib of Python 3.4 and so on.
  3. Ruby is not Rails. Yes, rails helps a lot to ruby to rise up. But now rails is big problem for ecosystem of ruby itself. In ruby community there is term "rails programmer" that much differs from ruby programmer. There is a lot of rails programmers but the knowledge of ruby outside of rails of most of them is lack pretty much.

So, It is totally your solution to stop programming in ruby. Ruby get losing its positions in competition with python, it's the fact. And I feel sick of it. I suppose it happens mostly because of marketing reason, not technical. Guido living in America has much more ability to promote python in Hi-Tech than Matz living in Japan. Plus Matz is pretty introvert guy. So...


Not really. Ruby has been always inferior to Python technically and practically. Python had cleaner C bindings (which enabled Numpy, Cython and numerous other libraries). Python code is easier to debug and maintain: more explicit, less metaprogramming, fails early, better documentation.

Python also had "threading" library for ages. And its Unicode support was much better than Ruby's even in the days of Python 2.

I find it's hard to take seriously OP's arguments about Rails being "the only tool" in 2008 (I remember writing easily maintainable MVC websites in Python around 2006-2007) and Rubygems being the only package library (PyPI appeared 2 years earlier).

It always seemed to me that the only reason to love Ruby is to know nothing about Python.


Actually I don't care what comes early or later. The point is what more or less comfortable to use in practice. It's absolutely subjective.
By example I am eager with Ruby for ability to write one-liners like:

ruby -e "Dir[\"./**/*.*\"].map{|i| File.dirname(i)+' '+File.extname(i)}.inject( {|h,a| h[a]+=1;h}.sort_by{|k| k[0]}.each {|k,s| puts \"#{k} => #{s}\"}"

This one for example calculates how many files of what types exist in current directory and it subdirectories. I write similar one-liners in bash CLI without editor. How to write similar things things in python, I have no idea.
I know Python pretty well. I use it everyday for ALM automation for already 3 years. But anyway there still is wondering things in Ruby for me.
Rails is "the only tool ruby need for" mostly for people that usually far anough from ruby community. It's just popular internet mem that far from actual state.

I don't envy any person that would support such "one liners", but here's the Python version:

python3 -c 'from pathlib import Path; from collections import Counter; from os.path import splitext,dirname; c=Counter(); c.update(dirname(x)+" "+splitext(x)[1] for x in Path(".").glob("**/*")); import pprint; pprint.pprint(c)'

which one is easier to read, what do you think?

Your claim that you know Python "pretty well" seems dubious.

Good engineering is about writing a code which is reliable and easy to maintain. In my experience, Ruby's track record is abysmal on both counts.

P.S. Since I'm in the golfing mood, here's an one-liner in a statically typed language, which would be OBVIOUSLY not as elegant as the wonderful Ruby, right?

echo 'package main; import "os"; import "fmt"; import "path/filepath"; func main() { c := make(map[string]int); filepath.Walk(".", func(f string, _ os.FileInfo, _ error) error {c[filepath.Dir(f)+" "+filepath.Ext(f)]+=1; return nil}); for k,v := range c {fmt.Println(k, v)}}' > /tmp/a.go && go run /tmp/a.go

To talk about "easiness to read", you should learn more about functional programming and Ruby, of course. It's difficult for everyone to understand text or code if language it's written by is not known well.

I'm impressed that you reach an insight that not all prog.languages looks the same good in different applications.
So you still need only couple of steps to reach things that I talk about in beginning. And everyday exercises is very good habits. So You are definitely on the right way. Good job!

But your way to discuss here is boring me. I don't see any point to continue talk in this style. Good luck!


1) Rails, out of the box, doesn't have (trend) - The current trend in webdev is to make sites that are so slow, most phones and laptops can't run them comfortably. I like this, because exactly zero of my clients want to arbitrarily exclude 95% of their potential customers because of fashion concerns they have never heard of and don't care about. I enjoy taking business from people who feel my style is "dated".

2) Typing holy war - I understand why dynamic typing and duck typing are less preferable, but in practice, I have never seen any of the major disasters that people predict.

3) Ruby is slow - See point one. My apps run pretty fast, and it's easy to be fast when the competition has 100% deprioritized speed.

4) Concurrency - Ruby doesn't have the best concurrency model, so on a project where that's important, I don't use Ruby. Hardly enough reason to abandon ruby altogether.


No. I will continue to use Ruby and whatever languages best addresses my use case. Fuck off with your stupid titles. Please stop writing shitty articles. Thanks. Fyi rails supports websockets and actioncable. And ops uses vms so just run a bunch of vms on multicore machines if you need concurrency and configure the appropriate port forwarding to apache nginx. Finally Airbnb and Shopify as well as Github are made with ruby and they make $$$. 1 man can do a lot with rails.


Stop posting articles here then, because this site is on Rails.


Have you ever tried JRuby? No GIL, true concurrency, all threads map to Jave threads. The speed delta is dramatic too.

Your app distributes as a war file to any j2ee server as well.


Yes, I once attended a JRuby workshop run by Charles Nutter at RubyConfAU. I was very impressed but at the time it was quite difficult to migrate existing apps. Maybe that's not the case any more?


I have always started with it. I fully expect it to be at least a bit of a pain to migrate any complex app.


If you commit to JVM world, then JRuby is a very rare choice, compared to excellent Kotlin, reasonably established Groovy and Scala or good-enough Java 8.


Try harder next time. JRuby is one of best options in the wild for you to go enterprise with Ruby.


Thanks all for the feedback. I agree that the title is a bit clickbait, but if I hadn't given this article this name would you have commented?

I agree with most of the points raised here (and on the Ruby NZ slack where I cross-posted it). I'm sorry if it appears that I'm shit talking Ruby and Rails. This is my day job too. We have a joke around these parts that Rails is "New Zealand scale" - ie perfectly good for most workloads in this country and I would tend to agree (although I've worked on a few projects now where that assumption was wrong).

I guess the point I'm trying to make is from a purely technical standpoint Ruby is not up to the job we're doing any more. I want to know what factors continue to support it's (obviously widespread) adoption.


Quick 2 cents. I used to think NoMethodError was a big drawback of Ruby/dynamically typed languages. Then I started working in Java and discovered Null Pointer Exceptions...


A lot of your article rang true with me as well. I feel like I had similar experiences. When I first discovered rails and needed to create basic RDB crud pages it was excellent. Once I started to need more than that, I felt like it was the wrong tool. I've moved on, but mainly because I can't stand using RDB.


Crystal addresses at least the speed issue. I'm surprised not to see it mentioned in the article or as a link in the better alternatives.


I've never heard of it, so there's that. :)

Googling now.


I love Ruby and Rails, but Mr. Harton has an opinion and that's fine. These issue aren't new, but I would point to Eileen Uchitelle's talk on the future of Rails, and as mentioned above progress continues to be made on Ruby itself. So I think it's fair to say that the respective core teams are not resting on their laurels. And as Mr. Cain pointed out, speed isn't everything. There's value in having such a large and vibrant community for instance.

Having said all that, it's perfectly reasonable for someone to eventually outgrow their tools. I can only speak for myself, but I'm not there yet. Ruby and Rails still have a lot to offer me.


I am on Windows and It's really painful to work with Ruby and Rails. So many bugs on Windows side for ruby. Often those SSL errors for installation and broken gems.


Without extensive tooling, a Windows machine out-of-the-box is especially painful to develop on,so Im not surprised. Compare this to other platforms where you login, fire up an editor and can start writing Ruby or Python or whatever out of the box without installing anything. I once mentioned this to a .Net developer and he suddenly became very angry. ..


Python support for Windows have been great for ages.
PHP community made an effort to ship Windows-friendly distributions.

Compared to those, Ruby have always been pure pain.


From the DEV CoC:

Examples of unacceptable behavior by participants include: Trolling



Yet another clickbait post attempting to become viral, but in the end just tries to make Ruby/Rails problems look bigger than it actually is.


Performance - there can be only one

The V8 team read that and laughed their asses of.


"the senior software engineer that I am today" you're very humble... jk


what a pointless article. also what is wrong with CPAN other than 'oh no its Perl'?


Yup, the article is so pointless it is really amazing why the author wants to waste our time. He is evidently a rails guy, so he never used ruby because of ruby. These people only harm a community since they are language hoppers. Hopping to other better languages is great, but a click bait such as "stop using ruby" is utter PR trash. I used ruby before rails, I still use ruby and I fail to see why I should move to another language. What for, anyway? Ruby achieves precisely what I need from a programming language, so why should I stop it? That is just so stupid from the author.

The author writes crap such as:

What this tends to mean in practice is that dynamic typing leads
to subtle bugs because the wrong object is in the wrong place
at the wrong time.

I have been using ruby since almost 20 years and I can happily say that this does not happen. There are no "subtle bugs".

Of course it makes a difference if you design a COMPLEX and COMPLICATED system. Don't do that. Stay simple. Stay elegant. Don't use every random feature because you are just an incompetent person who should not program.

I do not have "subtle bugs". I know what the code does, and the code ensures that what it does works. Input is checked; output is checked. All of this works without (!) having to write a SINGLE test. I don't test my code - and my code still works without a problem. (I actually do test the END functionality, so that when I rewrite a project after, say, 10 years, I do not forget some functionality that once worked. So I do still write tests for the overall COMPONENTS, but not individual shit such as unit tests - that would be totally pointless).

The author is just too clueless to write such articles.

Then he writes crap like this:

Let's get this out there first of all. Ruby is slow.

If you compare ruby to python, perl, php, then ruby is NOT slow. In fact, it has become much faster than before too. Ruby 3 is right now 1.8 times faster than ruby 2.0; and that does not yet include MJIT optimized to its fullest. Either way this is comparable to the other "scripting" languages, so what is this author's problem? The same applies to the others too, so ...

What the actual fudge.


This is a condescending article. It'd be great for the community if you kept your click-bait titles to yourself.

On a separate note, this site - yes, - which is fast as ⚡️, is built in RoR.

code of conduct - report abuse