David Masover
6/28/2008 7:25:00 PM
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.