It is very, very difficult to be as fast as C in an interpreted language, but it's true that with things like JIT you can get pretty close for some benchmarks.

Well there's a Ruby interpreter written in C, a Ruby VM (YARV) written in C, and there are Rubies that run on the JVM, .NET, LLVM, and Parrot VM. There's also a Ruby compiler front-end in progress to the gcc tool chain (ala gpc, gdc, etc.).



No C is just as far away from what you really get as are many other 2GLs.
Frankly, even old chestnuts like COBOL and PL/1 are as "powerful" as C IRT to direct machine access.

It isn't that languages are interpreted that makes them slower, so much, but what David mentioned about many things going on behind the scenes.

/* C */
int i = some_array[index];

That is directly translated into "fetch the integer at the memory position specified by some_array plus a number of bytes equal to the number 'index' times the size of the elements in some_array." Which is like maybe 3 CPU instructions to pull off (depending on architecture specifics).

# most script languages
i = some_array[index];

That is generally translated into "look up the variable named 'some_array' in the local scope's variable hashtable, look up index in the local scope's variable hashtable, look up the 'get index' meta method on the value we retrieved for 'some_array', invoke the meta method with both values we looked up, check that the passed in value from 'index' is an integer, check that the integer is greater than or equal to zero and less than the size of the array, return the value at the given index, store that value into the key 'i' in the local scope's variable hashtable, execute a post-statement interpreter hook.

Whew. If you've compiled this down to a compiled language, then you usually remove the stuff about looking things up in a scope's hashtable… but nothing else.

You can write similar code in C. C arrays aren't garbage collected, don't remember their length, don't automatically resize when you assign to an index past their end, etc. You can create a struct to represent an array with those features and then write some functions for manipulating them. You can write structs that can store mixed types and then use those in your program and have to add a bunch of runtime checks to every function to convert the mixed values into native values… but at that point, you might as well slap a nice grammar and a VM on top of it and make your life way less painful. Oh! That's what Ruby/Python/Perl/etc. all are! Well, there you go.

The question you should be asking yourself isn't "How much slower is Ruby than C?", it's "Is Ruby fast enough for what I'm doing?"

Considering that my old badly programmed DikuMUD could support 40 users when sharing a Sun 4/110 with the campus news server, and said Sun 4/110 was the equivalent of a intel 486/33 (a SPARC CPU running at 15MHz), I doubt the slowdown from Ruby being interpreted will matter that much, since the slowest machine I have in the house runs at 900MHz.

Now, if you aren't self-hosting, finding a provider that supports ruby may well be enough of a pain to stop you from using it, but that's true with anything outside the mainstream.

C is one of my favorite languages. But it has limitations, and for certain types of programming it is not ideal. For low level stuff like operating system kernels, it's great. When you start building really complex structures with it, especially ones which must be flexible and easily reconfigured, you will find it too inflexible. You spend an inordinate amount of time dealing with stupid crap that you would rather not deal with; i.e. header files, function prototypes, memory allocations, etc. You end up spend more time fighting with the compiler and dealing with low-level stuff than actually getting things done.

Every programming language has limitations and applications where they are not well suited. I encourage you to play around with as many of them as you can, because it will expose you to new ideas and ways of thinking. I recommend spending some quality time with Eiffel, Perl, Python, C#, and Ruby, in that order. Don't waste your time with C++ if can help it. It's garbage, and long-term exposure to it will likely cause brain damage. It's a terrible excuse for an object-oriented language, and for the applications where it's useful, there are much better choices available. (i.e. C#)

Clearly you must have learned that after many years of first-hand experience with it. ;)

Let's make COBOLMUD!

%kill Ccoder
Quixadhal's PIC(9999) clause ***SMASHES*** you for 7621 points of damage!

%who
IDENTIFICATION DIVISION.
PROGRAM-ID. Quixadhal.
AUTHOR. COBOLMUD.
INSTALLATION. Wizard.
DATE-WRITTEN. 05-MAR-2008.
SECURITY. Player.

C'mon… it'd be fun! You know you want to…. *grin*

To do it properly, you need a 2nd gen machine, so you can HALT the process and hack the code. Who wants to recompile and reboot? ;)



Yes, I firmly believe things have been going downhill since multitasking was introduced. ;)