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.
Ruby would be my choice for any application