Investigating Ruby - key limitations ?

[mortench]

I have been looking at the Ruby programming language recently. I like
Ruby and would like to use it myself but I see some several key
limitations that hinders use of Ruby in mainstream projects (and makes
it hard for me to recommend it for my customers):

1. Slow and very primitve VM - no jit, vm comparable to java 10
years ago.
2. No native thread support - this is increasingly a problem as
threading and multi-core technology becomes the norm (*)
3. No (first-class) unicode support (*)
4. Poor development enviroments compared to .NET/Java - however this
is slowly getting better - f.x. RDT is quite useful.

For more info see my blog at:
http://mortench.blogspot.com/2005/11/investigating-ruby.html

This is not a flame-invitation, but I would be interested in hearing
constructive feedback from more experienced Ruby developers to address
wrongs/shortcommings in my analysis.

 

[Matt Lawrence]

I have been looking at the Ruby programming language recently. I like
Ruby and would like to use it myself but I see some several key
limitations that hinders use of Ruby in mainstream projects (and makes
it hard for me to recommend it for my customers):

1. Slow and very primitve VM - no jit, vm comparable to java 10
years ago.

I have found Ruby to generally be fast enough. With the easy addition of
InlineC, the critical parts can be sped up by orders of magnitude.

Having said that, there is VERY active development by some incredibly
brilliant people to build a new VM.

So, right now it depends on how fast is fast enough for what you need.

2. No native thread support - this is increasingly a problem as
threading and multi-core technology becomes the norm (*)

That's an issue for a number of folks. It is being worked on along with
the new VM. I expect to see something soon.

3. No (first-class) unicode support (*)

Many of the Ruby developers are Japanese. I will have to defer to their
greater knowledge of m17n

4. Poor development enviroments compared to .NET/Java - however this
is slowly getting better - f.x. RDT is quite useful.

Different people want different things in a development environment. I'm
happy with X & vi. Others really like TextMate on OSX. There are even a
few preverts that use emacs

This is not a flame-invitation, but I would be interested in hearing
constructive feedback from more experienced Ruby developers to address
wrongs/shortcommings in my analysis.

Ok, there's my feedback. I think the current version of Ruby is very good
and the next version will be even better.

-- Matt
Nothing great was ever accomplished without _passion_

 

[Daniel Spiewak]

Ruby does have support for native threads in the form of Proc.new
However, it is recomended that you don't use them except for in
situations where you're doing long running tasks in native code. This
is because Ruby's lightweight threads spawn *much* faster than the
native Proc threads.

Oh, and technically Ruby doesn't have a VM at all, just an interpreter.
Except for in two special cases (AFAIK) Ruby isn't compiled at all
(there's a native cross-compiler for Ruby to a windows exe as well as
an experimental Ruby to some perverted Perl byte-code intermediate).


I do agree that IDEs for Ruby are quite limited. And really, there's
almost nothing for eRuby, which is to me the most useful application of
Ruby. For doing development on Windows, I've had to resort to using
Putty to hit a Linux server and using VIM remotely with the eruby
syntax hightlighting package. Works really well all things considered,
but it's still a less than perfect solution. I know there's a plugin
for Eclipse that's supposed to do eRuby, but since the web site is in
Japanese and the only translation is filled with special chars and
Japanese linguistic idioms, I've had a hard time experimenting with it.
Anyway, for most development, RDT works fairly well.

 

[Austin Ziegler]

I have been looking at the Ruby programming language recently. I like
Ruby and would like to use it myself but I see some several key
limitations that hinders use of Ruby in mainstream projects (and makes
it hard for me to recommend it for my customers):

1. Slow and very primitve VM - no jit, vm comparable to java 10 years
ago.

There is currently no VM in Ruby; it's currently all interpreted. This
is a bad comparison to make -- and YARV will be changing that. Also, as
others have pointed out, one needs to evaluate Ruby on its own merits.
Not how it compares to Java's performance, but whether its performance
is good enough for your own needs or if its performance for your needs
is *enough* slower to justify the higher cost and development time for
developing in almost any other language.

2. No native thread support - this is increasingly a problem as
threading and multi-core technology becomes the norm (*)

This is a limited problem right now as it is generally better to use
full processes in a pool with distributed communication. It is
something, however, that is being worked on to solve for those few
problem domains that truly require it.

3. No (first-class) unicode support (*)

This is actually a complete irrelevancy; Ruby *does* support Unicode in
the form of UTF-8. With iconv it can actually do pretty well converting
between. What you *can't* do without using certain configuration options
(mostly $KCODE=3D'u', IIRC; possibly compiling with oniguruma regex engine
instead of the default regex engine) is iterate by character through
Unicode strings. You can sling them around, however, just as you please
and Ruby doesn't care.

Most people who want "first-class" Unicode support don't know what they
want because they hear a set of buzzwords and their brain goes fuzzy
anyway. I'm not trying to suggest that this is you, but frankly your
line-item here is so terse as to be useless.

4. Poor development enviroments compared to .NET/Java - however this
is slowly getting better - f.x. RDT is quite useful.

This is a common -- but almost always nonsensical -- statement. Indeed,
Charles Petzold has recently asserted the rich IDEs rot one's
programming abilities (I agree, actually). What I find, moreover, is
that Ruby projects do not tend to have as many files, methods, or
objects as comparable Java projects would and are more naturally
divisible into complete subprojects increasing decoupling and
maintainability of the appropriate subprojects.

I doubt, for example, that the Ruby PDF toolset[1] will ever go over
10,000 lines -- it's at 5,000 or so now -- and I've already implemented
a huge chunk of the PDF specification for writing purposes. Its support
libraries (there are two) are less than 1,500 lines of code -- and most
of that is in color-tools specifying some common RGB colours.

-austin
[1] PDF::Reader, PDF::Core, and PDF::Writer. Only the third exists right
now, but the other two are targeted for mid-2006.

 

[Austin Ziegler]

I do agree that IDEs for Ruby are quite limited. And really, there's
almost nothing for eRuby, which is to me the most useful application of
Ruby. For doing development on Windows, I've had to resort to using
Putty to hit a Linux server and using VIM remotely with the eruby
syntax hightlighting package. Works really well all things considered,
but it's still a less than perfect solution. I know there's a plugin
for Eclipse that's supposed to do eRuby, but since the web site is in
Japanese and the only translation is filled with special chars and
Japanese linguistic idioms, I've had a hard time experimenting with it.
Anyway, for most development, RDT works fairly well.

Try using gvim on Windows.

-austin

 

[Daniel Spiewak]

Considered it, but I don't like the windows implementation of VIM. I
also looked into JEdit, but that wasn't terribly good either.
Actually, what it comes down to is that I hate adding more applications
than I have to onto my machine. I don't even have a Ruby interpreter
on my local machine, I run everything remotely. Call me a skinflint on
space, but I guess it is what it is.

 

[Martin DeMello]

Considered it, but I don't like the windows implementation of VIM. I

What didn't you like about it? I found it pretty similar to the unix
version, apart from a few keystrokes and clipboard issues.

martin

 

[Kirk Haines]

1. Slow and very primitve VM - no jit, vm comparable to java 10
years ago.

Speed is only relevant when you need it. I've been writing Ruby code for my
living since April 2002. I have many, many web sites and web based business
applications that I have done in that time running for many customers, and
the only times I have ever had a performance related issue was either because
I was simply being stupid with my algorithm or because of a bottleneck
outside of Ruby. I can conceive of tasks where I might want to optimize
parts of it, and for those parts, if I need it, I will either write an
extension of use RubyInline to tweak just those sections.

And YARV, when it is released, will likely eliminate almost any inclination
that I have to optimize through extensions or RubyInline.

2. No native thread support - this is increasingly a problem as
threading and multi-core technology becomes the norm (*)

This isn't that big of a deal. In-process threads have some advantages, and
most problems that could make use of threads can just as easily make use of
separate processes.

3. No (first-class) unicode support (*)

Not a big issue. I can write web apps that use a variety of different
encodings, and that converts between them with Iconv. Ruby doesn't care.
It's all just strings of data, I would think that given the large number of
Japanese users of the language, if this were really much of a problem, it
would have been addressed long before now.

4. Poor development enviroments compared to .NET/Java - however this
is slowly getting better - f.x. RDT is quite useful.

Also absolutely a non-issue. I kind of like Eclipse + RDT, but it is hardly
because of the rich Java-like goodness that Eclipse brings to my coding. And
while I have never seen a Ruby project that was so expansive that something
as simple as vim couldn't be used effectively, there are other options. Lots
of other options, and many of them are overkill for almost everything.
Eclipse certainly is. I like kdevelop quite a bit. It gives me almost
everything that I like form Eclipse without being such a resource pig. But
it's also overkill for many, many coding tasks. I just don't understand this
eagerness for a super-ide for Ruby, I guess, because I have never found a
need that wasn't already met. I added it up a couple weeks ago, and I have
close to a quarter million lines of code in production, and I have never seen
the need for a .net/java style IDE.


Kirk Haines



Kirk Haines

 

[Austin Ziegler]

What didn't you like about it? I found it pretty similar to the unix
version, apart from a few keystrokes and clipboard issues.

And the way that I've got my .vimrc and ~/.vim directories shared
between Unix and Windows, I *never* notice the difference

-austin

 

[Daniel Spiewak]

Basically, it was because it didn't fit in well with my workflow. i.e.
It didn't blend well with the rest of my Windows environment. For some
reason, I feel that Putty and vim on Linux works better (hey, it's my
psyche, I don't get it).

 

[Gyoung-Yoon Noh]

And the way that I've got my .vimrc and ~/.vim directories shared
between Unix and Windows, I *never* notice the difference

-austin

More funny thing on vim is we can write real ruby code in vim
context. It would have been thought as somewhat headache,
but it soon become interesting. ;-)

 

[Daniel Wislocki]

3. No (first-class) unicode support (*)

Not a big issue. I can write web apps that use a variety of different
encodings, and that converts between them with Iconv. Ruby doesn't care.
It's all just strings of data, I would think that given the large number= of
Japanese users of the language, if this were really much of a problem, it
would have been addressed long before now.

Actually what I've found is that most Japanese don't use Unicode at
all, but one of the other encodings like Shift-JIS. (I live and work
in Japan.)

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Investigating Ruby - key limitations ?"

|Actually what I've found is that most Japanese don't use Unicode at
|all, but one of the other encodings like Shift-JIS. (I live and work
|in Japan.)

Since Windows XP (and Max OS X) uses Unicode, the situation has been
changing, i.e. we are facing more complex encoding confusion by yet
another new encoding. ;-<

matz.

 

[Kev Jackson]

4. Poor development enviroments compared to .NET/Java - however this
is slowly getting better - f.x. RDT is quite useful.

Ah the old chestnut - no IDE, it can't be used in the 'enterprise'.
Programming Ruby with notepad/vi/vim/emacs is perfectly possible.
Instead of intellisense, actually *read* the docs and learn what methods
and properties are available. I've used VisualAge and more recently
Eclipse and the only thing that I'd say was absolutely superb about
Eclipse is the refactoring support. In general I know the standard API
well enough that the intellisense feature slows me down as it seems to
match the first character (and it frequently gets it wrong), and it's a
major pain when it pops up and you have to disrupt your typing to
dismiss it.

A ruby refactoring tool (lefactoring...) would be brilliant, but apart
from that IDE's really don't provide you with as much as you think.
Someone over at Microsoft recently wrote about how VisualStudio rots
your (coding)brain and I can only agree, since working on ruby (with
gvim/Scite), I feel like I'm actually thinking through the problems and
fixing them myself, instead of being led by the nose in Eclipse
everytime I type a .

YMMV...

but this is not a reason to dismiss ruby just yet.

FYI Komodo from activestate has recently added ruby support, the windows
beta version is available for download, I may look at it at some point

For more info see my blog at:
http://mortench.blogspot.com/2005/11/investigating-ruby.html

Kev

 

[Curt Sampson]

Actually what I've found is that most Japanese don't use Unicode at
all, but one of the other encodings like Shift-JIS.

Actually, the more technical Japanese folks seem to actively hate
Unicode, though I've never gotten a solid answer as to why that didn't
involve confusing glyphs with their representations. (Which I guess I
can see how it might upset you if your name came out with the wrong
version of the character--but besides being damn rare, we have solutions
for this.)

But I've done tons of Unicode stuff, and really, -Ku and the usual
libraries (iconv etc.) cover most of what you need, and if you need much
more, you're probably ending up with custom code anyway.

For the other stuff, take a careful look at how you're doing scaling.
It may be that with Java or whatever you're just going to run into the
same limits when you get ten times bigger, anyway, and when you switch
to what you need to do to really scale, it makes little difference what
you use because you're distributed amongst a huge number of hosts and
processes anyway.

And also consider using Ruby for some stuff, and not others. You don't
have to use it for everything, and in fact you probably don't want to.
But there are a fair number of cases out there where it's pretty darn
convenient and fast.

(I live and work in Japan.)

Shibuya, myself.

cjs

 

[Daniel Wislocki]

Shibuya, myself.

Osaka here.

 

[Curt Sampson]

Programming Ruby with notepad/vi/vim/emacs is perfectly possible. Instead of
intellisense, actually *read* the docs and learn what methods and properties
are available.

Actually, I'd find some better interactive support for exploring methods
and properties available on objects to be a big boon in the ruby world.
All the time I find myself getting back an object from a method and
thinking, "what the heck is it, and what can I do with it?" Ruby, with
no type information and poor documentation, and often no easy way to
recreate the situation in irb or whatever without going through a lot of
steps, is quite painful in this way.

Not that I like Intellisense much. In particular, I tend to be a
"top-down" programmer, I write the functions I wish existed, and worry
about actually implementing them later. That gets you into battles with
the IDE which wants your (not-yet-extant) functions to be ones that do
exist, or at least wants to create them before you're sure that you want
to.

Easiest thing to do in these circumstances is just to open up an editor
window in a standard text editor somewhere and type there, until you've
worked out what that bit of code or DSL or whatever really ought to look
like.

But here's an interesting opinion on Intellisense:

http://charlespetzold.com/etc/DoesVisualStudioRotTheMind.html

cjs

 

[Srinivas Jonnalagadda]

I have been looking at the Ruby programming language recently. I like
Ruby and would like to use it myself but I see some several key
limitations that hinders use of Ruby in mainstream projects (and makes
it hard for me to recommend it for my customers):

1. Slow and very primitve VM - no jit, vm comparable to java 10
years ago.

I would like to comment only on this point.

Everyday, I process files of the order of 1 GB in size. The
processing includes some computations, aggregations and rule-based
rewrites. On my desktop system (2.4 GHz, 512 MB RAM), it takes
between 13 and 15 minutes. I think it quite acceptable!

It has taken three iterations for the code to arrive here; but, it is
still pure Ruby (i.e., without any C extensions). As another answerer
said, a key factor is the choice of appropriate algorithms for your
requirement.

Best regards,

JS

 

[Austin Ziegler]

Actually, the more technical Japanese folks seem to actively hate
Unicode, though I've never gotten a solid answer as to why that didn't
involve confusing glyphs with their representations. (Which I guess I
can see how it might upset you if your name came out with the wrong
version of the character--but besides being damn rare, we have
solutions for this.)

I've done a bit of work with Unicode and there are two primary
objections to the Unicode standard and representations by Japanese
developers and users (I am generalising to CJK below):

1. The politics. The Eastern scripts were treated rather badly initially
and were painfully under-represented in Unicode 1.0 and probably
Unicode 2.0. I don't think that CJK were adequately represented until
Unicode 3.0, to be honest.

2. The political impact on representation. The existing CJK encodings
were/are relatively efficient for storing CJK, although some forms
used shift-in/shift-out byte markers, increasing the total number of
symbols that could be represented in a relatively efficent storage
format, even if processing time was a little slower.

In contrast, UTF-8 and UTF-16 are relatively inefficient. IIRC, most
Japanese encodings will use between 1 and 2 bytes per glyph. UTF-8
will use between 3 and 4 bytes per glyph. UTF-16 uses either 2 or 4
bytes per glyph.

-austin

 

[Devin Mullins]

Actually, I'd find some better interactive support for exploring methods
and properties available on objects to be a big boon in the ruby world.
All the time I find myself getting back an object from a method and
thinking, "what the heck is it, and what can I do with it?"

(Exuberant)? ctags might help with that. It's a fairly general 'search
for the file/line that defined this method'-type thing. That's all I
know about it.

Personally, I need basically three things in an IDE:
1. Indentation management. Auto-indents when you hit enter, and allows
you to indent/unindent blocks of text.
2. Syntax highlighting.
3. "Folder drawer." TextMate does this perfectly for me -- no bells, no
whistles, just an interactive view of my directory tree. This is
especially important for Rails, where you start off with a pretty fancy
tree from Day 0.

I'm pretty sure it's possible to get all that in vi (or, at least, vim),
but I'm way too lazy to set it up.

Devin