Friday, September 27, 2013

Rubyists, A Non-Endangered Species

Picture a circle of chairs in a church basement, a small group of people, faces holding anxiety and shame, but also a quiet courage and determination. In the background, a cheap table, a big metal cylinder full of hot coffee, and a stack of paper cups. Everybody's quiet. I stand up.

Me: "My name's Giles, and I read Hacker News."

Everybody: "Hi Giles."

Due to my shameful addiction, which I struggle daily to overcome, yesterday I heard about a GoGaRuCo talk called "Why Hasn't Ruby Won?", and today I learned of a Wired article which will no doubt fuel plenty of Ruby FUD for months (and maybe even years) to come:

Twitter’s engineers came to realize that Ruby wasn’t the best way to juggle tweets from millions of people across the globe — and make sure the site could stay up during its headline moment with the president of Russia. The best way was a brand new architecture based on Java, a programing tool that has grown more powerful than many expected...

Originally, Twitter was one, monolithic application built with Ruby on Rails. But now, it’s divided into about two hundred self-contained services that talk to each other. Each runs atop the JVM, with most written in Scala and some in Java and Clojure. One service handles the Twitter homepage. Another handles the Twitter mobile site. A third handles the application programming interfaces, or APIs, that feed other operations across the net. And so on.

The setup helps Twitter deal with traffic spikes. Because the JVM is so efficient, it can handle much larger amounts of traffic with fewer machines. But the new operation is also more nimble. All these services are designed to communicate with each other, but if one goes down, it doesn’t take the others down with it.

I'm very happy to say I found out about this through a rant which raises the obvious criticism, which is that the article utterly fails to differentiate between Twitter switching languages and Twitter radically overhauling its architecture:

quite frankly the choice of language may not be all that important.

You could take a monolithic application written in any language, break it down so that it scales horizontally across servers and vertically to provide separate systems that communicate with one another in exactly the same language you started with and end up with a system that is… *drumroll* …faster, more scalable and less prone to crashing.

So I don’t buy the line that Java or the JVM saved Twitter. I would bet that a thorough re-architecting of their system saved Twitter. I’d be glad to update this based on Twitter devs first-hand knowledge but I’d already happily put some money on the architecture being more important than the language, it nearly always is.

I've written two books on Rails, and both of them discuss refactoring to service-oriented architecture. I'm writing a third, and the first thing I do in it is give a newbie-friendly demo of one such refactoring. I've worked on a large number of Rails apps, stretching back to 2005, and one very consistent theme I've noticed is that most sites use a more complex, service-oriented architecture than the "omakase" architecture which Rails assumes as its default. (And even 37Signals uses services for some things.)

Nonetheless, the past two days seem to hold a theme of skepticism about Ruby's future.

Time for a history lesson: around the same time Rails first appeared on the scene, proving that you could build a successful company with Ruby, Paul Graham wrote his book Hackers And Painters, which made many programmers aware that you could build a successful startup on Common Lisp (as Graham did with Viaweb). Another terrific company at the time, DabbleDB, demonstrated that you could build a great web app with Smalltalk.

All you really have to do is write good software.

However, if there's any extent to which this Ruby skepticism needs any response, I think the response should be a more honest appraisal of "the omakase stack," or the odd differences between Rails's official "conventions" and the standard deviations from those "conventions" which people who build Rails apps will make, as a matter of convention.

One of the weird things about the Rails community is that Rails's progenitor and overlord David Heinemeier Hansson gives out advice on infrastructure which is very hard to take seriously, and advice on business which very obviously works, yet people seem, to me, to ignore his opinions about business while imitating his infrastructure and finding that it doesn't work for them.

As an aside, I'd like to see people take Mr. Hansson's business advice more seriously. I said above that "all you really have to do is write good software," but really, there's more to it than that. Thinking about business is not always what programmers are good at, but if you want to be free of the danger that you might have to give up your favorite programming language because somebody read a poorly researched Wired article and failed to notice its deficiencies, then all you have to do is write good software, and turn a profit.

But if we're concerned about people with heavy-duty traffic needs taking Rails seriously, I think the Ruby and Rails culture(s) would be wise to acknowledge that most people who use Rails ultimately disregard the "omakase" stack, or at least customize it, in favor of a more service-oriented approach. We can't encourage people to think of Ruby and Rails as the same thing and then complain when they fail to differentiate them, just like we can't encourage people to think that everybody uses Rails the way 37Signals does, and then scoff when they point out that the "omakase" stack is not well-suited for the needs of a business like Twitter (or GitHub, another hugely successful company which uses Rails in the context of a significantly more service-oriented architecture).