Shanti Bradford wrote a response to my rant. (Yes, it was a rant.)

I read the article and he makes some valid points. It’s a good pivot to summarize some of the things that came up in the discussions.

But then he wrote:

“[Terry’s article] makes the classic mistake of assuming (or implying) most apps will ever need to remotely scale to hundreds of thousands, if not millions, of requests a day (where Twitter currently stands).”

Time to pull out the can of whup ass! 😉

[Clarifying Ruby on Rails’s place in the world.]

A rant

At first I was angry. Then I realized that his list of “Respect” included Joel on Software and Paul Graham. The first guy makes his living selling a shitty version of Bugzilla. The second guy’s claim to fame is a “plan for spam” that actually increases spam by a factor of a hundred: which is obvious to any kid who’s taken a pattern recognition course in college (Ahh, what a misspent youth!) Market defects: the big blind spot in every libertarian.

(Given some of the reactions to Mark Pilgrim’s post and mine: “I’m joking, guys!”)

If you still thing this is a PHP vs. Rails thing, then please go to RailsEnvy. As someone points out, the only problem is the name of the website—the sort of thinking that goes into that title demonstrates the primary point of my rant. I could argue with the videos they have there, but I prefer to just enjoy them. You’ve got to give them points for both style and humor.

Getting serious

I’m actually not making that mistake he mentions: it’s too easy to say “Use PHP for highly scalable websites, use Rails for everything else” since neither is exactly true. If you read very closely at the rhetorical questions I mention about twitter, I feel that a combination of hype, time to market and low barrier to entry (Shanti’s Plan A) makes Twitter’s use of Rails justified. (The jury is still out until they’re profitable. On one hand a fellow developer from Yahoo! pointed out: “They can’t even keep IM notifications up!”; on the other hand, it’s still the best microblogging app going.)

I should have been more clear on some of my points:

1. The PHP world doesn’t need to take advice on how to run their community from the Rails world. As crazy as PHP is (and it is pretty crazy), it’s very clear which is the more mature language and community.
2. The twitter folks know more about scaling Rails than 37signals. Lecturing twitter from that position might provoke a “PHP terrorist” pointing out that you are standing in a glass house.
3. It’s not that Rails can’t scale, it’s that it doesn’t practically scale at this point. Investing in Rails for a viral application is asking to be the crash test dummy for others.
4. Writing code is about making choices. Using any framework? Some choices have been made for you. When you pick up one end of a framework, you pick up the others.
5. A la Pablo Picasso’s maxim: there are a lot of interesting ideas that are worth stealing from others. In fact most of the good things in a language were stolen from somewhere else. Yes, including PHP learning from Ruby. Stealing requires respect and understanding. That’s why I respect Rails.
6. I have my doubts about PHP stealing the core philosophy from Rails—the two approaches seem antithetical. There are a number of PHP developers trying to prove me wrong, which is a healthy thing if I turn out to be wrong!

Beyond scalability

Besides scalability, your future web application may map onto WordPress (like this blog and Shanti’s), Wikimedia, or various forums. It may be a support app like Trac, Bugzilla, SugarCRM, etc. The application download is always an option.

Or, finally, it could be just a quick fun hack like some of the apps being created to mashup some other sites REST APIs and run on various social networks. PHP excels at these things.

The Rails framework sits as optimal somewhere outside these area. I agree there are a lot of apps there. I don’t know what they are exactly, but there are a number of small projects (including 37signals’s applications) that fit in that area.

I notice that a number of Rails sites seem to be modeled around the one site per application/feature where that feature is too big for one-offs (where PHP is very good at and Perl is undisputed champion) and too small to really scale (when shared architectures engender a huge cost).

The siren’s song of Ruby

A number of non-programmers ask me, “What’s the deal with Ruby?” The answer is very dangerous. On one hand, “It’s all hype.” is wrong; on the other hand, the number of sites making the jump to Rails is just going to generate a lot of unnecessary business to Thoughtworks and OmniTI. (Yeah, I like both companies, but I like the people there more and, quite frankly, I know it’s no fun fixing a mess someone else created.)

Put simply, I think that Ruby on Rails is very seductive. I can relate when I read this experience. Maybe you can. Programmers like the clean design of Rails and hate the messiness of PHP. Rails is like a rounded rectangle and PHP is like a ball of nails. All I’m asking is for a programmer begin with the end in mind and survey the entire terrain before making a choice.

Here is a thought experiment: Most people ask: “Can you build WordPress in Rails? Can you build Wikipedia in Rails?” The answer to both questions is “Yes, and it’ll be damn quicker than PHP to boot.” I ask “Do you think Matt Mullenweg could have built WordPress in Rails? Do you think Jimmy Wales could have built Wikipedia in Rails?” There is a subtle but important difference. It takes a programmer of a certain ability to “get” rails. Even then, the programmer has to spend a lot of work at it—the ATK experience is normative for Ruby on Rails conversions. I think Matt would prefer to spend his time taking photographs and Jimmy would prefer to spend his time dressing in east asian clothing and ranting about Google.

I’m always proud of when I can explain a complex software architecture in a manner simple for a non-programmer to understand. That is the height of understanding and the basis for creativity. I feel for the web problem, PHP is it’s simplest answer—so simple that even a non-programmer can express their answers creativity.

That’s why I said: “There is an opportunity in the listener’s institutions where PHP is a very powerful tool, very easy to understand, waiting for the listeners to use to build these amazing complex systems by stringing these simple things that PHP gives us.” When you choose another language you close yourself off to that potential.

You can really create a slow flawed spaghetti architecture. You may make a site that is insecure and easy to hack. You really do have to work hard to winnow the wheat from the chaff when hiring developers. There are consequences to a choice. If PHP was so perfect, then it would have a supermajority of the top websites instead of just a plurality.

The danger of simple prescription

The more general problem is that people are going to read this article or the previous and want a simple prescription. Yesterday, Kit Seeborg, heard my rant and started to worry for a project written in Rails. I’m not a fear monger. I don’t want her to worry.

My answer to her was this anecdote: Did you know the #1 social network out there, MySpace, was originally written in ColdFusion? At nine million users, they used a tool to translate ColdFusion into ASP.NET and I imagine some of their stuff is written and reoptimized in C# today.

There is a path. A programmer just has to find it. Maybe it’s JRuby. (I doubt it will be that simple, a performance gain is nice, but certain large sites scale exponentially—you’re going to have to do something about a framework that wasn’t built with scalability in mind.)

Twitter is trying to find it. In the meantime, I suffer the cats that have taken over their servers. I’m a consumer, if I’m pissed enough, I’ll switch to Jaiku. That’s what they mean when they say, “the market has spoken.”

On scaling Rails

On an anecdotal level scaling issues hit Ruby on Rails sooner than you think. I’ve heard about a number of mongrel scaling issues at much smaller size than Twitter. (Twitter’s problem is passed mongrel scaling into the area of database federation.)

Mongrel issues show the point where a shared-none “architecture” starts paying off. Basically Ruby on Rails (and other shared/threaded models including some from the Python world) require meticulous coding to avoid these problems. PHP doesn’t.

One of the most quoted things in the office recently was when I said: “PHP is a good language for the web because it doesn’t give you anything to shoot yourself in the foot with.” It’s a strength and it’s a weakness.

Personally, this leads to my feeling that the best area for Ruby on Rails is internal enterprise applications, where the upper bound of scale is well determined (company or team size). Some friends of mine feel differently, and that Rails can be the right choice for many customer facing applications. That’s okay. The fact that I root for the Pittsburgh Steelers doesn’t mean that I refuse to talk with a Cleveland Browns fan about football. Of course, we don’t argue about the fundamentals, like a good offense or a good defense, either. If you read the articles I linked you’ll see the differences, but more importantly, you’ll see commonality.

Making choices

I can’t emphasize this enough:

Writing software is about making choices.

One of my favorite interview questions for a senior developer is asking them to explain a programming design pattern, what the consequences are, and when to use and not use the pattern they chose. It’s actually shocking how many programmers can’t. Choices have consequences. Not realizing that makes you a design pattern bigot.

Be honest about the consequences of your actions: whether it is the programming language you choose, a framework/no-framework you adopt, a design pattern you apply, or the choice to simply download someone else’s application and install it. Choose wisely. A lack of self-reflection leads to a poor choice and spells disaster.

I am definitely not saying that the PHP community is so great or the language is so perfect. Ever hear of Friendster?