Announcing Topaz: A New Ruby

Completely unscientific, but if these outputs are any indication, this is going to be great news for Rubby users in the future...<p><pre><code> $ time ruby -e "puts 'hello world'" hello world real 0m0.184s user 0m0.079s sys 0m0.092s $ time ~/Downloads/topaz/bin/topaz -e "puts 'hello world'" hello world real 0m0.007s user 0m0.002s sys 0m0.004s</code></pre>

I'm all for new Ruby implementations, but be very careful about judging performance of an incomplete implementation.<p>It's "trivial" to make a fast language that looks quite a bit like Ruby. It is a lot harder that make a language that remains fast in the face of handling all the quirks of the full Ruby semantics, though, such as selectively handling the risk of someone going bananas with monkey-patching core classes that could happen at any "eval()" point.

For those with long memories there was a (in)famous <i>Topaz</i> project in the Perl world. This was an attempt to implement perl5 in c++. It was abandoned however it did help kick-start Perl6 &#38; Parrot.<p>refs:<p>- <a href="http://topaz.sourceforge.net" rel="nofollow">http://topaz.sourceforge.net</a><p>- <i>Topaz: Perl for the 22nd Century</i> <a href="http://www.perl.com/pub/1999/09/topaz.html" rel="nofollow">http://www.perl.com/pub/1999/09/topaz.html</a><p>- <i>Historical Implementations/Perl6</i> <a href="http://www.perlfoundation.org/perl6/index.cgi?historical_implementations" rel="nofollow">http://www.perlfoundation.org/perl6/index.cgi?historical_imp...</a>

I will be the first to ask: why did Alex / the pypy devs start this project? I thought the three community funded ideas were great (STM, Python 3, and Numpy). What prompted this new project? Is it meant to attract new developers to pypy as platform for implementing languages? Is it a side project? Is it a long term project meant to become the premium implementation of ruby as pypy is becoming for python? Etc.<p>Not criticizing at all by the way, just curious about the motivation / background / context for the project, which is missing from the docs.

It would be nice to see Rpython/pypy turned into a project not unlike WebKit where many different projects benefit from the same open-source core. If pypy is flexible enough to implement all of ruby and all of Python, has a reasonable amount of maturity, and is already rather fast it seems like a good candidate for such a thing.

Forgive me for asking what may be a very stupid question: Can someone explain to me the need for a Ruby interpreter built on top of Python? He mentions performance in the announcement, but is this really going to be faster than, say, MRI? Thanks in advance.

I'm curious to see how this compares to MRI/Rubinius/JRuby once it's feature-complete; the PyPy vs. CPython benchmarks these days are pretty convincing.

Does Topaz benefit at all from the work that's been done already on Rubinius? I seem to recall that Rubinius implements as much of Ruby in Ruby as possible. It seems like this would help Topaz as well in implementing the standard library. Or are the implementations different enough that this doesn't work?

I'm probably in the minority but I would love to see a dialect of ruby that has significant whitespace. Death to unnecessary 'end's

Sweet, I'm very interested in this. I assume this implementation has a GIL? Any word on how threads will be implemented?

Implementing other languages on top of the PyPy toolchain is an interesting concept, and I'd like to see it happen more often. But calling this "Ruby in Python" is sure to invite flamewars from all sides. The actual Topaz site seems to be careful not to do this, but if this thread is any indication, a fair number of people are already mistakenly calling it that.

<a href="http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.html" rel="nofollow">http://blog.headius.com/2009/04/how-jruby-makes-ruby-fast.ht...</a><p>At least once a year there's a maelstrom of posts about a new Ruby implementation with stellar numbers. These numbers are usually based on very early experimental code, and they are rarely accompanied by information on compatibility. And of course we love to see crazy performance numbers, so many of us eat this stuff up.

If it doesn't have all of Ruby's weird features, claims of speed don't matter, because it's those weird features that make Ruby slow and hard to optimize.

Could this lead to a runtime in which I can use really cool ruby modules from python and really cool python modules from ruby? I mean, seriously, these two languages both have some pretty awesome stuff, and regularly I say about one, "man I sure wish I could use $module from the other".

Any reason for not targeting Ruby 2.0?

Excellent news. I wish this project the best of luck. More competition in the Ruby implementation field is always a good thing for end users, it fosters innovation and provides choice and a good kick in the ass to everyone.

I've been wondering why the tools the PyPy people have been building are not used to implement more languages. It's nice to see this happening. And it will be interesting to watch where this leads.

Doesnt mention what the current status of topaz is with respect to <a href="http://rubyspec.org/" rel="nofollow">http://rubyspec.org/</a>

I mean, it's cool that people want to expose Python's version of Rubinius as a building block to yet another Ruby interpeter, but, come on. Why is this a thing?! Why not waste time improving the JVM, contributing to Rubinius, patch the MRI, or a million other open source projects already tackling Ruby being "slow". By the way, has anyone else realized that, while Ruby is slow, <i>computers</i> are getting faster for us too!

Sounds really interesting, but we already have a dozen of incomplete alternative Ruby implementations...

Just curious, for this project did you set out to write it in idiomatic ruby or idiomatic (R)Python?

So Ruby on top of RPython on top of PyPy? Why not, but how does it compare to JRuby and Rubinius?

So... GIL?

RPython is the new C?

Topaz as a name? Seriously? (<a href="http://topaz.sourceforge.net/" rel="nofollow">http://topaz.sourceforge.net/</a>)

Why not implemented on Erlang OTP? Ruby and Python share the same scaling issues, so I don't see a benefit it combining them or migrate from one to the other.<p>I also dislike the "high performance" claims without showing a single performance comparison. Not to mention the state of implementation completeness of the language.