From: David Masover <ninja@...>
Date: 2008-06-29T04:24:35+09:00
Subject: Re: Where does ruby excel?

On Saturday 21 June 2008 08:08:34 Dolazy wrote:
> I have only used ruby for writing little scripts. Things that are
> typically done using Perl/awk/bash...  Ruby has the potential for much
> more, but there doesn't seem to be a problem domain where it truly
> excels. Maybe Rails, but that's a bit controversial (would it carry
> large websites like Amazon or Facebook?).

Answer: It already does, to some extent.

The trick is, first of all, programmer time is more important than 
performance. If you can throw another ten servers at a problem instead of 
another ten developers, that is a massive win.

And second, Rails is designed to encourage a share-nothing style of app, which 
makes it horizontally scalable. That means you can actually just throw more 
hardware at the problem. Obviously, it's more complex than that in practice, 
but nothing as big as Amazon or Facebook will ever work without being 
horizontally scalable.

> On the client side Javascript seems to be the big winner. It is the
> plugin language for Firefox, and in the future it may even become a
> standard choice for desktop software development (with Adobe Air).

That hasn't happened yet. Until it does, we still have things like Shoes for 
true desktop apps, and various tweaks to get Ruby into JavaScript. There's 
already IronRuby, for .NET, which means you could theoretically use Ruby in 
Silverlight, and I'd be surprised if no one ports Ruby to Tamarin, which is 
the bytecode engine used for Javascript/Actionscript in Flash (and in future 
versions of Firefox).

> For what kind of software would ruby be the
> programming language of choice?

Anywhere I can -- I like the syntax. What I would ask is, for what kind of 
software would ruby _not_ be suitable for?

I have three answers:

First, anywhere that you can't actually run Ruby right now. For now, it's 
better to write the client side of a web app in Javascript -- but that's no 
reason the server side can't be Ruby.

Second, anywhere performance on a given set of hardware is important. You 
might well write a word processor or a spreadsheet in Ruby, but you probably 
wouldn't write a fast-paced first-person-shooter in Ruby -- at best, you 
might use Ruby to script it, once the engine has been written in C/C++. And 
many embedded controllers would physically not be able to load the Ruby 
interpreter, let alone an app.

And third, anywhere you actually need to work at a low-level -- in C or ASM. 
Things like bootloaders, device drivers, and bytecode compilers are probably 
not practical in Ruby -- and this is also generally an area where #2 applies 
as well. (If you want the game to run fast, the video driver must be fast as 
well.)

As a side note, if a project has a very tight deadline, it might make sense to 
use whatever currently has the libraries you need. If something exists on 
CPAN, but not in Rubygems, you'll be using Perl. But that's mostly related to 
#1 -- things Ruby hasn't been ported to, or things which haven't been ported 
to Ruby.

What does that leave?

Quite a lot, actually. I plan to write a filesystem in Ruby. It doesn't need 
to be fast, as I know for a fact that the underlying medium will be very slow 
(recordable DVDs) -- and I can use the Ruby FUSE bindings.