Ruby 1.9.1 Released

Janwedekind writes "Yuki Sonoda yesterday announced the release of Ruby 1.9.1 (Ruby Inside coverage with lots of links). The VM of Ruby 1.9, formerly known as YARV, was initiated by Koichi Sasada and has been in the making for quite some time. Ruby's creator Yukihiro Matsumoto has already presented many of the upcoming features in his keynote at RubyConf 2007. Most notably, Ruby 1.9 now supports native threads and an implementation of fibers. A lot of work also went into encoding awareness of strings. The 1.9.1 version is said to be twice as fast as the stable 1.8.7. It will take some time though until the majority of existing Ruby extensions get ported to 1.9."

Comments

Re:Twice as fast...

[bstadil]

Too busy to just google for 2 sec before spouting off?
Here is jRuby using java VM , Maglev using Smalltalk VM , IronRuby using MS .Net , or pure Ruby Rubinius>Rubinius all aimed at among other execution speed.

Re:Twice as fast...

[bstadil]

Sorry it wasn't clear. No it is Ruby implemented to run on a Virtual Machine. You write your Ruby code as normal and it gets compiled to byte code that run very fast. This is how Java is fast. Ruby can in principle be as fast as Java. Ruby is not inherently slow just the current implementation is somewhat slow.

Re:Twice as fast...

[LarsWestergren]

JRuby is an interpreter, written in Java. It does not compile Ruby to Java bytecode.

Incorrect. I certainly DOES compile Ruby to Java bytecode. Read the blogs of Charles Nutter, John Rose and Ola Bini for more information.

Re:Twice as fast...

[BerntB]

I still do Perl.

Half the reason is that Perl is a bit insane and breaks all language design rules -- but still works. That makes it fun. The other half is that the community is so good; CPAN is a result of that and, also, you don't have so much of that disgusting hype (like you just commented on); like you, I'd rather not be identified with a community doing that.

Ruby do look sweet and Python seems usable (if a bit boring). But with the "Perl Best Practices" book becoming so popular and Moose (et al), I can't motivate a switch. The largest problem with Perl today IMHO is that it takes a bit more time and energy to learn.

Re:Ruby vs Python

[ubernostrum]

Then again, your complete post is content-free except for some handwaving about "deep knowledge" and "cursory familiarity".

...snip...

The fact that method calls (assert, print and del) are included in the language syntax, means that Python is not (yet) fully OO.

Well, actually understanding what's going on does require a bit of knowledge of the way the languages work, but my point was that it's irresponsible to go from an assertion like "up until Python 3.0 print was a statement" to "Python isn't really object-oriented" or "Python's OO is just bolted on", because even a basic understanding of how Python works shows that to be false. Let's consider an easy example, a simple function which adds two numbers (Slashdot's comment system will eat the indentation of the function body, but that's neither here nor there):

def add(x, y):
return x + y

You might call this function by writing add(2, 3), which would return 5. That turns into a method invocation, delegating to the __call__ method of the function, which is an object: add.__call__(2, 3). And that, in turn, expands into an invocation of the __call__ method of the class of the function object, with the function object passed as the first argument to get the self reference, and the rest of the arguments following: types.FunctionType.__call__(add, 2, 3) (all functions in Python are instances of FunctionType, which is accessible through the types module if you ever have a need to do things manually without resorting to Python's function-definition syntax).

From just this simple example it's clear that the object-orientation really does go all the way down, and that the existence of the print statement in older Pythons was a "bolted-on" wart of an OO language rather than being the other way around. The same is true for the other "special" statements in Python; these are not vestigial remnants of some non-OO language which got an object system tacked on, they are bits which were added on to an OO language for pragmatic reasons (print was turned into a function in Python 3.0, but assert and del, remain as special cases).

This also reveals a few interesting points of Python/Ruby comparison:

• Just as many things which appear to be "standalone" functions in Ruby are actually methods on Kernel, which is implicitly available everywhere, many things which appear to be "standalone" functions in Python are actually members of various modules (and are exposed at the toplevel through Python's implicit __builtins__ module, which also provides a handy way to access the original objects if they're being shadowed by something user-defined; if a name is not found in local scope, any enclosing scope or global scope, __builtins__ is the last place Python will check before raising a NameError).
• But, Python's style of OO is different than Ruby's; Ruby has a message-passing OO system, where there really are no "method calls", just objects which respond to messages of particular names (the syntax hides this somewhat, but if you poke at it you'll see this is how Ruby does it), while Python has a method-invoking OO system. This is why Python requires parentheses for function and method calls: the parentheses are the syntax which invokes the __call__ method of a callable object, just as, for example, "/" is the syntax which invokes the __div__ method of a (numeric, or number-emulating) object. In this sense the parentheses can be thought of as an operator of slightly higher-than-normal complexity (they are not actually an operator in the sense of being recognized as such by Python's lexical analyzer, however, because parentheses are used for other purposes depending on context).
• Although both languages are object-oriented a