[Updated May 24, 2016: now with more salt]

There's been some chatter about how Ruby on Rails is dying / doomed / awful.

Make Ruby Great Again

...can a programming language continue to thrive even after its tools and core libraries are mostly finished? What can the community do to foster continued growth in such an environment? Whose job will it be?

Rails is Yesterday's Software

We need new thinking, not just repackaging of the same old failures. I should be spending time writing code, not debugging a haystack of mutable, dependency-wired mess.

My Time with Rails is Up

As a result of 9 freaking years of working with Rails and contributing like hell to many ruby OSS projects, I’ve given up. I don’t believe anything good can happen with Rails. This is my personal point of view, but many people share the same feelings.

Ruby in decline...

The significance of the drop in May and the leveling of is that "Ruby does not become the 'next big programming language'".

Whoops! That last one is from 2007. To summarize the various comments I've seen on Reddit, Hacker News, blogs, articles, and talks lately, here are some examples stuffed with the finest straw:

Rails Doesn't Scale

This canard hasn't aged well. My uninformed college-student argument in 2006 was: "You don't scale your language or framework, you scale your application." I had never scaled anything back then, but over ten years later I still agree with young-dumb-and-loud college me.

Your language or framework is rarely the bottleneck: your database, network structure, or background services are where things will slow down. ActionCable may or may not get two million plus connections per box like a trivial Elixir app, but you can always deploy more app servers and workers. And I'd worry those Elixir connections will end up waiting on Redis or Postgres or something else - your language or framework isn't a magic bullet.

You can also extract services when Ruby and Rails aren't the right tools for the job. Many Ruby gems do this by binding to native C extensions. Extracting a service for machine learning models can take advantage of Python's different memory model and better ML libraries. Your CRUD app or mobile API doesn't have to do it all.

Ruby is a Messy Language

In Ruby you can re-open any class from anywhere. You can access any object's private methods. Duck typing is everywhere. People make weird DSLs like RSpec. Rails is chock-full of magic in routing, database table names, callbacks, and mysterious inheritence. Ruby and Rails are easy, but they're not clear or simple.

This blast from the past is a 2007 argument. Since then we've learned tons about how to write expressive-but-clear Ruby. Rails isn't going to keep you safe by default, but you can and should try to write clear Ruby on top of it. I've found the following super helpful when refactoring and designing code:

Solnic in particular felt like his attempts to reduce complexity, tight coupling, and shenanigans in Rails were actively mocked by DHH and others in the community. If true, that's awful, and I would hope most of our community isn't the ActiveMocking type. DHH has certainly said Rails won't trade convienence for cleanliness by default. I don't think that precludes cleanliness and safety when the code and team get big enough to need it, though.

A programming language isn't a magic bullet here, either. I've seen people hold up Java as an example of explicit, clear code with sanity checks and few surprises. Well, here's some Java code for an Elasticsearch plugin, with comments stripped, spacing cut down, and truncated for brevity:

public class LookupScript extends AbstractSearchScript {
    public static class Factory extends AbstractComponent implements NativeScriptFactory {
        private final Node node;
        private final Cache<Tuple<String, String>, Map<String, Object>> cache;

        public Factory(Node node, Settings settings) {
            this.node = node;

            ByteSizeValue size = settings.getAsBytesSize("examples.nativescript.lookup.size", null);
            TimeValue expire = settings.getAsTime("expire", null);
            CacheBuilder<Tuple<String, String>, Map<String, Object>> cacheBuilder = CacheBuilder.builder();

Now here's a "magical" plugin for ActiveRecord, Paperclip. Truncated for brevity, but nothing stripped out:

module Paperclip
  require 'rails'

  class Railtie < Rails::Railtie
    initializer 'paperclip.insert_into_active_record' do |app|
      ActiveSupport.on_load :active_record do

      if app.config.respond_to?(:paperclip_defaults)

    rake_tasks { load "tasks/paperclip.rake" }

The latter seems vastly more readable to me. You may need to read the docs on what some of the methods do, but I had to read an awful lot more to grok the Elasticsearch plugin. Since we're in the era of musty old arguments, I'll bring up the amazing AbstractSingletonProxyFactoryBean again.

Ruby gives you enough rope to hang yourself. Javascript helpfully ties the noose and sets up a gallows for you. Java locks you in a padded room for your own good. Elixir uses a wireless shock colla... wait, sorry. That metaphor got weird when a functional language jumped in. Point is, you can write terrible code in any language, and some languages make that a little easier or harder depending on your definition of "terrible." Ruby strikes a balance that is my favorite so far.

Rails Jobs are Drying Up

Here's some data I found by asking colleagues, Googling and poking around:

Rails isn't achieving the thunderous growth percentage that Javascript and Elixir are, but percentage growth is much harder to achieve when your base is already huge.

On further discussion and analysis, this is actually insanely hard to measure. Javascript is on the rise, for sure - but how many Javascript StackOverflow questions are for front ends that exist inside a Rails, Django, or Phoenix app? How many Node.js apps are tiny background services giving data to a Java dumpster fire? Where do you file a full-stack job?

Languages and frameworks don't just disappear. You can still find a decent job in COBOL. Ruby and Rails will be with us for a long time to come.

The Cool Kids™ Have Moved On

These are people I look up to, and significantly contributed to my understanding & development in Ruby.

Of course, many of the "movers-on" are still part of the Ruby + Rails communities. Sidekiq for Ruby isn't going anywhere - Sidekiq Enterprise is pretty recent, and Mike has a commendable goal of making his business sustainable. Yehuda has been at RailsConf the last two years, and works at Skylight - a super cool performance monitoring tool with great Rails defaults. Searls has also been at RailsConf the last two years, and as he said to me on Twitter:

...my favorite thing about programming is that we can use multiple languages and share in more than one community 😀

~ @searls

Sanid Metz and Aaron Patterson have been fixtures in the community, and they don't seem to be abandoning it. Nick Quaranto is still at RailsConf. And of course, Matz is still on board.

Plus, a mature community always has new Cool Kids™ and Thought Leaderers™. I've found lots of new people to follow over the last few years. I can't be sure if they're "new" or "up and coming" or "how the heck am I just finding out now." Point is: the number of smart Ruby & Rails people I follow is going up, not down.

The above-mentioned Katrina Owen, Sarah Allen, Godfrey Chan, Richard Schneeman and others are all people I wish I'd known about earlier in my career.

I'm Still Pro-Skub

Ruby and Rails make a fantastic environment for application development. Rails is great at rapid prototyping. It's great at web apps. It's great at APIs - even better now that Rails 5 has an API-only interface. The Ruby community encourages learning, thoughtfulness, and trying to get things right. Resources like books, tutorials, screencasts, and boot camps abound. Extensions to Rails to help keep code clean, DRY, and organized are out there. Integrations with SaaS products are plentiful.

If you're looking to learn a new language or just getting started in web dev, I'd still recommend Ruby and Rails before anything else. They're easy enough to get started in, and the more you read and work with them, the better you'll get at OOP and interface design.