Quality of Ruby Implementation?


#1

Much of the discussion concerning Ruby focuses on the language itself
and on how enjoyable it is to program in. I’m still a Ruby novice but
I agree with these sentiments. However, I have not heard much
discussion about the quality of the Ruby VM implementation. How
good/mature/production ready is it? So far I’ve used it for simple
development tasks/utilities but not in production.


#2

I was wondering why noone responded (besides the fact that I mistakenly
asked about the quality of the Ruby VM when its actually an
interpreter)? I considered the question an earnest one and did not
intend to be trolling.

Interestingly, Avi Bryant has a post on his blog
(http://smallthought.com/avi/?p=8) suggesting that Cincom make it
possible to run Ruby in their Smalltalk VM.

Gary Blomquist


#3

GJB wrote:

I was wondering why noone responded (besides the fact that I mistakenly
asked about the quality of the Ruby VM when its actually an
interpreter)? I considered the question an earnest one and did not
intend to be trolling.

Timing? Most posts, (even trolls :slight_smile: ) get a prompt response on this
list, but every so often a message just gets lost in a swirl of threads
and off-list activity.

Offhand, I’d say that after 13 years of development the Ruby interpreter
is pretty robust.

James

http://www.ruby-doc.org - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools


#4

From: “GJB” removed_email_address@domain.invalid

I was wondering why noone responded (besides the fact that I mistakenly
asked about the quality of the Ruby VM when its actually an
interpreter)? I considered the question an earnest one and did not
intend to be trolling.

Not sure what particular measure of quality you were asking
about - but for what it’s worth, I run some multi-user quake
server admin software written in Ruby that consistently operates
for hundreds of days of uptime, until I eventually reboot the
server or quit the application intentionally.

It uses TCP and UDP networking, and keeps a fairly large dynamic
in-memory data structure (100 megs or so)… I also dynamically
reload code modules without quitting the application on a periodic
basis, when adding simple new features or making bug fixes.

I’ve been pleased with Ruby’s stability so far, if that helps.

Regards,

Bill


#5

On Dec 1, 2005, at 7:23 PM, Bill K. wrote:

It uses TCP and UDP networking, and keeps a fairly large dynamic
in-memory data structure (100 megs or so)… I also dynamically
reload code modules without quitting the application on a periodic
basis, when adding simple new features or making bug fixes.

Hi Bill,

Just wondering if you’re able to share more about your application?
It sounds interesting.

Thanks,
Steve


#6

Hi,

In message “Re: Quality of Ruby Implementation ?”
on Fri, 2 Dec 2005 11:12:32 +0900, “GJB” removed_email_address@domain.invalid
writes:

|I was wondering why noone responded (besides the fact that I mistakenly
|asked about the quality of the Ruby VM when its actually an
|interpreter)? I considered the question an earnest one and did not
|intend to be trolling.

Maybe because we are not sure about your criteria of quality. Besides
that, I didn’t want to be self-compliment.

						matz.

#7

Hi Stephen,

From: “Stephen W.” removed_email_address@domain.invalid

It uses TCP and UDP networking, and keeps a fairly large dynamic
in-memory data structure (100 megs or so)… I also dynamically
reload code modules without quitting the application on a periodic
basis, when adding simple new features or making bug fixes.

Just wondering if you’re able to share more about your application?
It sounds interesting.

Thanks - well, technically there’s a rubyforge project:
http://rubyforge.org/projects/dorkbuster/
But the documentation is very meager / nonexistent.

Also, I’ve learned a bit about Ruby since I first wrote it,
so I wouldn’t recommend some parts as shining examples of
good idiomatic ruby code; especially the parts using threads
and mutexes. (Some modules could be simplified quite a bit.)

I’d design some parts of it rather differently if I were to
do it over. . . . Etc.

Pragmatically speaking, though, it works. :slight_smile: Multiple admins
are logged into it at any given time to monitor server activity
and watch out for cheaters. We’ve been using it for about three
years now.

A brief overview of what it is/isn’t:

  • Allows multiple admins to log in over telnet and monitor
    quake 2 servers, and issue bot scans and rcon commands
    without admins knowing the actual server rcon password.

  • Provides an optional “windowed” interface using ANSI
    telnet scrolling regions, and supports line editing and
    command history. (No tab-completion, yet.)
    Windows show admin chat, live server status, and raw
    server log data.

  • Keeps a database linking player names to player IP’s,
    and shows a sorted list of most recently/frequently
    used names for each player connected.
    The database is currently stored in-memory (checkpointed
    to disk on a periodic basis), and can get quite large.
    I’ve intended to switch over to a traditional database
    engine (sqlite/mysql/postgresql).

  • Provides hooks for “droids” (like IRC bots) to connect
    to the admin system and provide additional functionality,
    such as bot scans or running player-driven map rotations.
    (The map rotation droid is provided with the project.
    The bot scanners are private, as it’s difficult to stay
    ahead of the cheaters.)

  • Currently, no automatic cheat-detection scans are
    performed. (We use a third-party module on our servers,
    q2admin, to provide some level of cheat auto-detection.)
    Strange as it may sound, the lack of automated scans in
    dorkbuster is somewhat by design. I think the key reason
    dorkbuster is actually effective is the presence of
    multiple human admins monitoring the servers pretty
    much around the clock. So db’s design has been focused
    on providing a collaborative environment for live admins.
    Some automated scans might be nice - but not if the result
    were to reduce the level of human participation. So we’ll
    proceed carefully. . . .

  • As yet, no way to monitor multiple servers from a single
    telnet window. This is at the top of the to-do list.

Thanks for your interest. I’m happy to answer questions either
on or off-list, as appropriate.

Regards,

Bill


#8

GJB wrote:

The problem with your question is that we have no idea why you think
that Ruby is not suitable for production. How is the quality of the VM
lacking?

Ruby is used in production, there are big, well used systems written in
Ruby. Which all goes to make you sound like a troll and would account
for people ignoring you.


#9

On Dec 1, 2005, at 10:23 PM, Bill K. wrote:

Thanks for your interest. I’m happy to answer questions either
on or off-list, as appropriate.

Sounds cool Bill, thanks for sharing.

–Steve