Investigating Ruby - key limitations ?

Discussion in 'Ruby' started by mortench, Nov 7, 2005.

  1. mortench

    mortench Guest

    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.
     
    mortench, Nov 7, 2005
    #1
    1. Advertising

  2. On Tue, 8 Nov 2005, mortench wrote:

    > 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_
     
    Matt Lawrence, Nov 7, 2005
    #2
    1. Advertising

  3. 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.
     
    Daniel Spiewak, Nov 7, 2005
    #3
  4. On 11/7/05, mortench <> wrote:
    > 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 *
    * Alternate:
     
    Austin Ziegler, Nov 7, 2005
    #4
  5. On 11/7/05, Daniel Spiewak <> wrote:
    > 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
    --
    Austin Ziegler *
    * Alternate:
     
    Austin Ziegler, Nov 7, 2005
    #5
  6. 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.
     
    Daniel Spiewak, Nov 7, 2005
    #6
  7. Daniel Spiewak <> wrote:
    > 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
     
    Martin DeMello, Nov 7, 2005
    #7
  8. mortench

    Kirk Haines Guest

    On Monday 07 November 2005 2:07 pm, mortench wrote:

    > 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
     
    Kirk Haines, Nov 7, 2005
    #8
  9. On 11/7/05, Martin DeMello <> wrote:
    > Daniel Spiewak <> wrote:
    > > 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.


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

    -austin
    --
    Austin Ziegler *
    * Alternate:
     
    Austin Ziegler, Nov 8, 2005
    #9
  10. 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). :)
     
    Daniel Spiewak, Nov 8, 2005
    #10
  11. On 11/8/05, Austin Ziegler <> wrote:
    > On 11/7/05, Martin DeMello <> wrote:
    > > Daniel Spiewak <> wrote:
    > > > 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.

    >
    > And the way that I've got my .vimrc and ~/.vim directories shared
    > between Unix and Windows, I *never* notice the difference ;)
    >
    > -austin
    > --
    > Austin Ziegler *
    > * Alternate:
    >
    >


    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. ;-)

    --
    http://nohmad.sub-port.net
     
    Gyoung-Yoon Noh, Nov 8, 2005
    #11
  12. > > 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.)
     
    Daniel Wislocki, Nov 8, 2005
    #12
  13. Hi,

    In message "Re: Investigating Ruby - key limitations ?"
    on Tue, 8 Nov 2005 11:10:57 +0900, Daniel Wislocki <> writes:

    |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.
     
    Yukihiro Matsumoto, Nov 8, 2005
    #13
  14. mortench

    Kev Jackson Guest


    > 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
     
    Kev Jackson, Nov 8, 2005
    #14
  15. mortench

    Curt Sampson Guest

    On Tue, 8 Nov 2005, Daniel Wislocki wrote:

    > 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
    --
    Curt Sampson <> +81 90 7737 2974
    Make up enjoying your city life...produced by BIC CAMERA
     
    Curt Sampson, Nov 8, 2005
    #15
  16. > Shibuya, myself.

    Osaka here.
     
    Daniel Wislocki, Nov 8, 2005
    #16
  17. mortench

    Curt Sampson Guest

    On Tue, 8 Nov 2005, Kev Jackson wrote:

    > 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
    --
    Curt Sampson <> +81 90 7737 2974
    Make up enjoying your city life...produced by BIC CAMERA
     
    Curt Sampson, Nov 8, 2005
    #17
  18. mortench wrote:
    > 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

    > 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.
     
    Srinivas Jonnalagadda, Nov 8, 2005
    #18
  19. On 11/7/05, Curt Sampson <> wrote:
    > On Tue, 8 Nov 2005, Daniel Wislocki wrote:
    >> 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.)


    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
    --
    Austin Ziegler *
    * Alternate:
     
    Austin Ziegler, Nov 8, 2005
    #19
  20. Curt Sampson wrote:

    > 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
     
    Devin Mullins, Nov 8, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Pep
    Replies:
    14
    Views:
    466
  2. M P
    Replies:
    1
    Views:
    560
  3. Mario T. Lanza
    Replies:
    1
    Views:
    102
    Clifford Heath
    Aug 23, 2007
  4. Kyle Schmitt

    Limitations of ruby's XMLRPC?

    Kyle Schmitt, Nov 30, 2007, in forum: Ruby
    Replies:
    1
    Views:
    299
    James Edward Gray II
    Nov 30, 2007
  5. Alexey Petrushin

    Limitations of all Ruby ORMs

    Alexey Petrushin, Jun 8, 2008, in forum: Ruby
    Replies:
    3
    Views:
    157
    Alexey Petrushin
    Jun 16, 2009
Loading...

Share This Page