Blog

Art | Bicycling | Food | Hacks | Making Stuff | Music | Wirehead
Home | Mail | Search
WireWorld > Hacks > Wirehead on Hacking > 9 reasons why you should build a website in Ruby, even if you don't use Rails

9 reasons why you should build a website in Ruby, even if you don't use Rails

1 Everything that's fast to write in Perl is just as fast in Ruby

This is the biggest, handiest, friendliest benefit of Ruby. You know how Perl lets you bash out a five line program that tweaks data in a specific way and spits it out? Well, Ruby lets you do that too. Except that you can read it afterwards.

Everything else is fast to write too. Things like being able to iterate over a collection (regardless of type) of things (also regardless of type) using the each function are features that I just miss in other languages now.

2 Ruby is a general purpose language, not 6 layers of hacks on a home page generator

Some people consider being able to insert code right into an HTML page a benefit. I do not. If you want to do that with Ruby, you can. Or you can do a code-behind style system like Rails and ASP.NET in a small bit of code. Or any other way that you've programmed.

And remember, Ruby's always let you write standalone apps. The "embedded ruby" engine is nothing but an added library. Always has been. So you can have it whatever way you want!

3 Ruby is a scripting language that won't make you feel dirty

Ruby was built from the start to be a clean language that happened to do string operations very well. It has that inner beauty that Lisp or Smalltalk has, but without the attitude problem of your average Lisp junkie. So you can use it to write the same code you'd write in PHP, but then you can write really sophisticated stuff with it too. And it's not going to be any harder.

What you realize after using Ruby long enough is that most of those shorthand bits that are there as syntactic sugar to make it easy to get started are all just functions in the core library. I edited a book on Perl and all I felt was surprise that people were able to actually make the language parse.

4 If you need something hard, Ruby doesn't get in your way

I often try and convince C++ programmers to play with Ruby, simply because I'm known as a hardcore C++ programmer and I don't miss it when I'm using Ruby.

I watched a system developed in PHP get ported to C++ because it was just not fast enough.

It wasn't pretty.

Ruby was designed from the start to let you link in binary modules to do hard stuff like encryption or media transcoding or stuff. It's nearly effortless to cross the boundary, so if you run into a situation where you can't toss hardware at things anymore, you can just do a few bits here and there in C/C++ and leave the rest alone.

People rag on Ruby folks for writing some portion of their code in C. What they forget is that you can do that to an existing framework without trying to rewrite everything else. It's easy!

5 If you don't use Rails, you can build it to your tastes just fine

People rag on Ruby because of Rails. See, Rails is brilliantly constructed and solves a bunch of problems very efficiently, but it's only one way to do things. I read an article about the cdbaby guy rewriting everything in PHP after a long experiment with Rails. Many of his arguments fall apart if you just write it all over in Ruby without Rails because there is so much more to Ruby than rails!

6 On the other hand, if you have a Rails problem, you can still use Rails

I tend to think of Rails as a brilliant solution to a useful subset of all possible website development problems. I mean, If Rails solved all possible problems, why does my wife still get mad at me when I make too many puns?

When you want to solve things that way, you can use Rails. I rewrote a fairly hefty and obnoxious internal system at work the other day with Rails in one day. This is the same power that I got when I rewrote proprietary software with MS Access and some grunting. Except that Rails is easier to build upon, works over the web, scales better, and I don't feel greasy after doing it.

7 Brilliant Ruby hackers make your life easier

A sufficiently powerful language (like C++ or Lisp but not PHP) will let you transcend what you think the limits are of a language, if you sit down and really understand it.

But you don't have to be that sort of hacker to take advantage of this. One hacker can write a good library and one hundred thousand programmers can benefit. But it's much easier for a good hacker to write a neat library instead of writing extra language features and then getting all of the implementers to actually implement it.

8 Ruby plays well with others

mod_ruby lets you embed parts of a new Ruby system into a legacy PHP website.

Ruby can load standard DLLs and call into them. There's even a library to do that without writing any code on the C side.

Ruby can call COM objects on windows.

You can embed Ruby in code written in any other language. There's also a library to do this without any fancy coding.

9 Ruby is on its ascent, not status quo

Ruby's on a good part of its development. See, we're at the point where you don't need to write your own CGI, XML, or database library to use it. But there's plenty of libraries that are at the 0.6 point that need somebody to push them to 1.0. You can still write something in a hundred lines of code that would take a thousand lines of any other language and people will be impressed because not everybody's doing it.

Comment posted on 2007-12-17 04:46PM by Fabio Cevasco:
Interesting post. Indeed Ruby is very elegant and crystal clear, that's one of its biggest strengths, imho.

"You know how Perl lets you bash out a five line program that tweaks data in a specific way and spits it out? Well, Ruby lets you do that too. Except that you can read it afterwards."

^ Agreed 100%

I recently wrote a quick overview mainly focusing on Ruby's syntactical beauty:

http://www.h3rald.com/articles/10-reasons-to-learn-ruby

Performance and speed... well, that will come. Definitely 1.9 is going to be faster, that's for sure!
permalink
 

Post Comment

Copyright 2007, Ken Wronkiewicz
Version 4.0
Last Updated: 2007-12-17 10:10AM
Posted: 2007-12-17 10:10AM