From: Michael Brooks <michael.brooks@...>
Date: 2008-04-30T13:50:04+09:00
Subject: Re: What are the weaknesses in Ruby?

tenxian wrote:
> What are the disadvantages of Ruby?

Hello tenxian:

I came to Ruby from Delphi (and to a lesser extend C/C++, Visual Basic, 
Python and various other languages) and find the following, in my 
opinion, to be the greatest issues:

1) For my situations Ruby has been between 2 and 80 times slower than 
Delphi (Delphi is roughly equivalent to C++ in speed).  Loop, 
calculation and in-memory data processing intensive operations (like 
calculating prime numbers, reading XML files, and image processing) are 
closer to the 80 times and programs that call out to optimized libraries 
(like OpenGL) for heavy-lifting are closer to 2 times.  Most of the Ruby 
programs I've written use more optimal algorithms than in Delphi because 
Ruby's flexibility and richness but the speed difference is still 
noticeable in all the situations I've come across (i.e. in one situation 
I used Ruby's powerful reg expressions to avoid looping which made the 
Ruby program only 32 times slower instead of 80 times slower than 
Delphi).  Previous discussion on this forum have suggested complimenting 
Ruby with C routines for the speed-sensitive parts.  Speed may not be an 
issue for you depending on your target application type.  For example, 
DB applications often do their heaving lifting in the DB itself via SQL 
or procedural SQL.

2) GUI applications are much harder/slower to write in Ruby than in 
platform specific (i.e. Windows) RAD environments like Delphi.  Ruby's 
GUI agnostic (note: Ruby does come with support for TK but I don't 
consider that a serious option) approach is an "advantage" but it also 
means that you don't get an "out-of-the-box" visual GUI building 
environment like with Delphi, .NET or Java.  There are some tools to 
make GUI building a little easier for Ruby but they aren't, in my 
experience, close to the same ease and productivity as those other 
environments.  However, having said that... I use wxRuby for GUI and 
like a lot of its object model much better than the Windows equivalents. 
  This is particularity evident in components like the wxGrid.

3) Ruby can't build stand-alone compiled single file executables like 
Delphi (or C/C++).  This becomes a concern if you write programs / 
utilities that you carry around with you from desktop to desktop and 
want to run with a double-click without an install or want to minimize 
concerns about incompatible library/API versions across different PCs. 
It also becomes a concern for protecting your intellectual property or 
when trying to make it difficult for someone to crack your security, 
authentication, encryption, or game scoring system.  Another concern 
along these lines is that you never really know on a given platform what 
exact version of a library / component is going to be pulled into your 
program the Ruby "require" statement because it's platform and install 
specific dependent.  In Delphi the many libraries are "compiled" into 
the EXE so it's rare that I hit incomparability on different PCs.


Everyone's mileage will vary and you'll need to balance issue like the 
above with the richness and productivity that Ruby provides in its 
syntax, cross-platform and cross-GUI capabilities.  These may not be 
issues for you, particularly if you're writing server side code with 
ties to other stable services/APIs that do heavy lifting for you.

I love Ruby... it's made coding fun again and I've generally been 
writing non-GUI stuff in Ruby 3 to 5 times faster than the equivalent 
Delphi programs.  However, the issues I've mentioned make it difficult 
for me to consider releasing software outside a server or single desktop 
environment or into a "commercial" setting with the same ease / 
confidence that I'd release equivalent Delphi or C/C++ programs.

Ruby 2.0 should minimize many of these issues.  In addition, JRuby and 
the .NET flavors of Ruby address most of these issues in various ways.

Just my thoughts... Don't take my comments as gospel.  You'll need to 
research these topics for yourself and listen to feedback from others to 
decide which things are *real* concerns for you.

Michael