In Search of Everything All at Once

I love programming, and luckily its what I do for a living. However, making up your mind as to what technologies to use on a project is one of the hardest (and sometimes most agonizing) parts to me.

Back in the Day...

The first language I learned in programming was BASIC, which whetted my appetite. I then needed more control over the hardware (hey, this was before modern operating systems), and learned assembler and then moved to C/C++. I used Visual Basic as well for Windows applications but then the web happened, and web programming was becoming something worth doing.

Discovering PHP

My initial work was in Perl. I wasn't terribly good at Perl, but then you didn't have to be to write some basic CGI scripts. Around that time though, PHP was coming into version 3 and offered freedom from all of the problems with Perl and how time consuming it was to write web applications with it. Since PHP was designed for the web, outputting the content type and such weren't necessary. It was a major step forward, and up until about 2005 I coded many PHP applications and websites, many of which are still in use today.

Love at First Sight

Then came Ruby. I fell in love with it, and then Rails came along. Rails was finally my excuse to use this wonderful language on the web. The screencasts made it look so easy - and it was. The beautiful object oriented nature of Ruby (in my opinion, unmatched by any other language), made complicated things seem like trivial tasks.

The first few Rails applications I wrote I was very happy with, but deployment and performance were always sticking points. Rails applications run very well for small loads, but require more babysitting when things get more intense. Our company took on larger Rails consulting jobs and eventually came to provide server management services for a top 5 Rails site. The challenges of dealing with Rails deployment woes were overcome by hard work, diligence, and experimentation, but we still ended up in most cases using three or four times the hardware to get the same thing done we did with PHP, or even Perl.

I suppose its normal to expect a more complex language like Ruby to execute slower, since there's considerably more overhead. The Ruby on Rails creator has said that CPU cycles are cheaper than developer cycles, and while this statement is certainly catchy, it's tough to convince someone paying for those CPU cycles that this is the case.

The Price of Ruby

Just how bad is the performance and development overhead? It's considerable. It takes at least four times the hardware and twice the administration (if not three times) to keep a Rails application running over a PHP or Perl application running.

Rails completely blows away many of the concepts that have been established so long for shared web hosting. Many web hosts that support Rails even still prohibit long running processes unless they're Rails mongrels or FastCGI processes. A host can no longer fit near as many sites on one server with Rails because Rails applications not only use 30 to 50 MiB of RAM per mongrel/dispatcher but leak RAM too like a sieve, even in production mode.

Of course, some problems faster languages won't solve. You still have to deal with SQL and data storage scaling, caching, and a host of other challenges big applications and websites face. You just have to deal with them considerably sooner than with Rails.

Time Well Spent

I've been pretty hard on Ruby, and on Rails in this article, but I will say that it has made me a better programmer. I now look at code in other languages and think its ugly, or think of more ways than I ever did to make it more maintainable and performant.

One of the problems that many PHP applications in particular face is the lack of separation between code and HTML. This isn't a failing in the language, rather a failing of the process of developing a PHP application. Just like you can write terrible code Perl, C, or pretty much any other language, PHP makes it easy to do. SQL injection attacks were really the only thing you can blame the language for, and since version 4 they have been working on that to the point that if you have an SQL injection problem in your PHP script, it is either because you're not using mysqli or you have register globals turned on.

Where Do We Go From Here?

I'm not leaving Ruby, has some developers have. I'm sticking with it. I'll not only continue to work with our existing Rails applications, but will still write new ones. However, I'm not going to make it the only choice for web development anymore. Languages like PHP will get much more attention now, and I'll use it just as much, if not more.. I'll take the wonderful design concepts that I've learned from my time with it and apply them.

I've given Python a look, but haven't been sold on it yet. I know it's faster than Ruby, but deployment is still no where near as easy as PHP.

It's possible in the future that Ruby's performance and web deployment problems will get to the point that there is no appreciable difference in applications written in Ruby, PHP, Java, Python, or anything else. That's probably far off though, and until then I need to offer both us and our clients a performant platform that is affordable and easy to deploy on. It may take a bit longer to write applications in, but the time I'll save will be returned to me by not having so many deployment and performance headaches.

We'll still have to scale, we'll just be able to do it at a slower pace and at less expense. Sure, a few more developer brain cycles may be used, but they will be more on getting things done.

This isn't an end to this saga though. This field is constantly changing, and one of the worst things you can do in it is stick with one thing forever and be afraid of things that are new.