

Rubinius Announces Plans for GIL Elimination, JIT Improvements, Targetable VM - cscotta
http://rubini.us/2011/02/17/rubinius-what-s-next/

======
poet
Beautiful example how a combination of open source enthusiasm and commercial
interest can generate some first class software. There's no way this could
have happened without Evan's initial enthusiasm or Engine Yard's support. TBH
I can list off dozens of open source projects that are one sponsor away from
another level greatness. :P

~~~
updog
You mean, can generate some _plans_ for some first class software. ;)

~~~
gregwebs
my understanding is that rubinius is production ready (and "first class")
software today. If they could offer a real performance improvement over MRI
1.9 they would be more compelling. Rubinius is also a much more compelling
environment to develop the Ruby language in, but they just don't support
Windows and all the 1.9 changes yet.

~~~
joe_the_user
I would say that Rubinius needs to be _significantly_ faster than MRI _and_
production ready to be successful. Otherwise, it's an "option" and having
"lots of interesting options" at the level of your language is actually
detriment to your development process. As someone said, you want your setup to
be "as boring as possible" so you can concentrate on your application code
instead.

Having "lots of exciting choices" in your web server, your database, your
object server, your language implementation, or monitor size just says your
time will be sucked from real work.

<almost a flame> I have been _tempted_ , in the past, to wildly claim that if
you compare Rubinius' relative failure compared to PyPy, Rubinius is kind of a
poster-child of Test Driven Development's failure. IE, languages need semi-
formal specs, not tests that claims they are a standard (no amount of testing
can prove two implementation equivalent). </almost a flame>

<CAVEAT>But listening to the PyPy folks describe their process, I realize this
stuff is uber-hard and I'd just like to hear what a real compiler developer
would say about this. </CAVEAT>

~~~
poet
This rant seems misplaced. Rubinius adopted a test driven approach for testing
Ruby compatibility because Ruby doesn't have a spec, merely a reference
implementation. The spec is being worked on, but the fact that it doesn't
exist has more to do with Matz and Ruby's culture than Rubinius. Further, your
other objections also appear to be rooted in a misunderstanding of Ruby's
culture. The fact that there are lots of choices in the Ruby's ecosystem is
what Ruby is about. Hell, choice is built right into Ruby with its inheritance
model. Python is the opposite, and I'm guessing that's what your background is
in.

~~~
joe_the_user
I'm not sure not if software development questions should be solved with a
reference to "Ruby's culture". Wouldn't "what works best" be a better
criteria?

I've done more Ruby than Python altogether. It's true that I am no longer
doing Ruby - mostly because it is too slow for anything beyond a fairly simple
web platform (I would welcome an improvement in Ruby performance).

I would argue that the time spent on the tests could instead be spent on an
actual spec.

~~~
poet
Did you stop programming in Ruby before 1.9.1? Most common performance issues
were fixed in that release. If you need something faster than 1.9.1, you
probably should be dropping down to C anyway.

~~~
joe_the_user
C++ for the desktop actually...

The thing is; C# and Java are also fast enough for an adequate desktop GUI.
But they're horrible to program in.

Ruby and Python are still in about the same category of slowness even with
pypy's success. I'm doubtful of Python desktop apps but I know they are out-
there.

------
jshen
You can also use jruby now. I'm not trying to diminish rubinius, I hope it
works out well and I worked with one of the contributors, but I've been using
jruby for a while now and it's great.

------
ekidd
This is really great news: I spent some time digging around in the Rubinius
JIT in December, and realized that it wasn't going to generate significantly
better code until the byte codes were replaced with an intermediate
representation that made type checks visible to the optimizer.

In the long run, Ruby implementations will be at least 1 order of magnitude
faster than either MRI 1.9 or JRuby. And I'm glad to see that the Rubinius
folks are taking the necessary steps to get there.

------
clyfe
Does any python implementation have non-GIL threading?

~~~
kingkilr
Both Jython and IronPython. PyPy probably will in the future, however its not
a goal at the moment.

~~~
tmorgan
pypy also supports stackless style microthreads:
<http://codespeak.net/pypy/dist/pypy/doc/stackless.html> but, yes, system
level threads are GIL based.

------
glenjamin
I've never been massively keen on the carious implementations of ruby, they're
all a bit different and those differences appear to be documented poorly. This
is most visible if compared to the python landscape.

~~~
tierack
I don't have a handle on the Python implementation landscape, but the various
Rubies all regularly contribute to rubyspec[0] and report on how they're
doing. And with rvm[1] it's incredibly easy to test code across rubies. From
where I'm sitting, it seems dead simple to find the differences and how they
could affect me.

0: <https://github.com/rubyspec/rubyspec> 1: <http://rvm.beginrescueend.com/>

~~~
glenjamin
I admit I perhaps haven't looked into this as much as I perhaps should have
before making that claim.

My understanding is that the rubyspec project (<http://rubyspec.org/>), is an
effort to retrospectively document all the stuff the language does.

Compare ruby: <http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9>, to python:
<http://docs.python.org/dev/whatsnew/2.7.html>

I appreciate this isn't a great example, as python 2.7 isn't a different
implementation (ruby 1.8 -> 1.9 is though), but this has been my experience of
the way things are documented language-wise.

