Ruby is my language of choice for many applications because of the
following:

(1) the lack of boilerplate. It encourages you to partition your problem
into small digestible bits because you only need to type

class Foo
...
end

to get a class - virtually zero effort. Compare the line noise required
in Perl to do the same thing.

(2) the supremely sane data model - *all* values are references to
objects. (In Perl you have Scalars, Arrays, and References to Arrays,
the latter being held in a scalar variable, and a load of special case
nonsense like filehandles and typeglobs. C++ is worse; you have
integers, pointers to integers and references to integers).

(3) pure personal preference, e.g. I don't like python's run-off-a-cliff
indentation syntax. I had to use it in Occam years ago, and I didn't
like it then either.

(4) the ruby 1.8 C intepreter ("MRI") is portable and runs on lots of
things, even tiny embedded systems with 4MB of flash (e.g. OpenWrt)

(5) it's easy to work in different programming styles. Functional
languages made a lot more sense once I was familiar with things like
blocks and enumerables in ruby.

(6) it's not Java.

The downsides for me are a lot of accumulated warts and special cases in
the language, generally aimed at "doing the right thing" but sometimes
catching you out. Examples: auto-splat, lambda-vs-proc-vs-block,
different behaviour of ^ and $ in regular expressions. I also detest
ruby 1.9's String handling which means I'm staying on 1.8; I know I'll
ultimately have to move to a different language entirely.

The documentation is variable from poor to bad. The language is not
formally defined, neither its syntax nor semantics, and sometimes you
just have to treat it like a black box and experiment to find out how
things actually behave.

Sometimes it can be hard to find your way around other people's code,
because ruby doesn't enforce that class Foo::Bar is defined in file
foo/bar.rb (or that it's even defined in source code at all; it might be
defined dynamically at run time). You're reliant on the good sense of
the person who wrote the code to organise it sensibly, and you can write
bad code in Ruby just as in any other language.

Finally, in some spheres there are simply better tools for the job. If
you want to handle ten thousand concurrent client connections then
erlang is probably a better fit (yeah, there are event-driven libraries
in Ruby which with effort can achieve the same, but this is an area
where erlang excels). Ditto if you want to build systems with huge
uptime and zero-downtime live code upgrades. But try deciphering an
erlang backtrace and you'll wish you were back with ruby.

HTH,

Brian.
--
Posted via http://www.ruby-forum.com/.