

Rubinius 1.0 (Fabius) Released - icey
http://rubini.us/about/one_point_oh

======
ezmobius
This is my favorite project we have at Engine Yard. I've been rooting for it
and fighting to keep it alive for years now because I know that this is the
future of ruby. Evan and Brian and all the contributors have done great work
on this ambitious project.

I've had ruby aliased to rbx on my own personal laptop and run all of my
development on rbx, I only have to bust out MRI every once in a while, like
once a month. I write lots of code with event machine, redis, amqp and many
other complex parts of ruby ecosystem and for the most part they all just work
on rbx.

Huge congrats to rubinius team again, I predict this will be the default ruby
for most people inside of a year if not 6 months.

Rubinius is ruby done right IMHO.

~~~
sandGorgon
what is the performance as compared to Enterprise Edition ?

~~~
jshen
I ran a benchmark on a library i'm working on (fuzzy auto complete), and
rubinius was the fastest (I didn't test 1.9).

The code is pure ruby, it creates a decent sized trie then walks it once to
set data in each node (a sequential forward index, etc).

I'll release the code once my library is ready for public consumption, but the
numbers were (in seconds):

rubinius ~ 4.85

jruby 1.5 ~ 5.45

mri 1.8.7 ~ 9.35

ree 1.8.7 ~ 9.35

and Yes, I did a warm up.

~~~
headius
I'd love to see your benchmark to understand why JRuby wasn't faster than
that. I assume you ran with the --server flag to JRuby as well.

------
bruceba
One thing I'd appreciate with these kinds of announcements is a "what is it"
paragraph preferably towards the top of the referenced web page. I suppose if
I were working in Ruby I'd know what Rubinius is and why I'd care but a list
of "what is new" doesn't particularly help me or folk like me.

~~~
SkyMarshal
Was going to say the same thing. Just looked through the site trying to find
exactly what it is, and all I got is:

1\. It's a Ruby implementation.

2\. It's mostly compatible w/ Ruby & its components (Rails, gems, etc.) but
not completely.

3\. ... ?

An About page would be nice - answer these questions, among others:

1\. What is Rubinious?

2\. What differentiates it from Ruby?

3\. What problems does it solve?

4\. Why would Ruby programmers want to use it?

5\. Why would non-Ruby programmers want to use it?

~~~
alexitosrv
I'm so clueless as you.

From <http://rubini.us> you can read "An environment for Ruby, the programming
language that provides performance balanced with accessibility, focusing on
improving programming productivity"

The thing is, in this context, what is "an environment for ruby"?

------
wavesplash
Congrats to Evan and the team!

Now that 1.0 is out, how about adding a blog and a mailing list?

I'd love to see Rubinius pick up a large following. IRC-only makes it a
challenge to build a thriving community.

~~~
evanphx
We have a mailing list at <http://groups.google.com/group/rubinius-dev>,
though it hasn't taken off much yet. Perhaps now that 1.0 is out people will
use it more.

Blog wise, what would you like to see on a Rubinius blog?

~~~
wavesplash
Would love to see a big fat link on the front page that says "Help make the
best Ruby implementation ever. Join us!" with a link to the google group.
Clear call to action.

Blog wise: Bubble up some of the great activity going on behind the scenes.
Design decisions, great implementation debates, calls for help on hard/easy
problems, new releases, beta releases, testing calls, etc. The posts don't
have to be more than a paragraph or two. Just enough so we can see where you
guys are steering the ship and if there's something we can do to help.

I'm sure there are more than a handful of potential up and coming language
implementers that Rubinius could help inspire and recruit. All it takes is an
easy to find/read active conversation to get them engaged.

Also, I'm sure you're thinking about a 'the long road to 1.0' post. That would
be great first post to talk about all the decisions and direction changes that
lead up to the current design.

~~~
evanphx
I think now that we've hit 1.0, the path forward is easy to break up into bits
could be on the blog. Before the 1.0-rc cycle, it was hard to separate out
individual things.

Given that people think this is a good idea, I think we'll go ahead and do it!

~~~
petercooper
Please do! The number of vaguely interesting Ruby blogs that are updated
frequently has taken a tumble in the last year or two. I need more to link to
;-)

------
daveungerer
I'd like to see if / how many of my unit tests pass using Rubinius, but does
it currently support 1.9-specific code?

Also, RVM installs RC2, not the 1.0 release. Maybe someone can give them a
poke...

UPDATE: Nevermind, <http://rubini.us> clearly states that 1.9 compatibility
will happen post-1.0. Can't wait, even if it's just to know that my code is
compatible with what may be a very real option in the years to come.

AND: I should probably run "rvm update" first, to get the 1.0 release...

~~~
earcar
Just updated rvm and can confirm 1.0.0 it's there.

------
mark_l_watson
Very cool! I use Ruby 1.9.1 and JRuby 1.5 for production, but Rubinius may
become dominant in the future because of using LLVM and because the code base
must be much easier to work with.

------
daveungerer
OT: I really like the HTML diagrams on <http://rubini.us/>. Is there a library
that does that or are they hand-built?

~~~
evanphx
Those are done by hand.

------
diptanu
Now this is where Ruby is winning, so many different implementations, and that
too successful ones! I love the community. Congratulations to the team. :-)

------
anin_teger
I'm just starting to get into Ruby but I'm pretty confused about this project.
It sounds really cool, but doesn't Ruby 1.9 already have a GC and compiles
into byte code? Maybe 1.9 doesn't have a JIT but couldn't they add it?

~~~
Freaky
Ruby has had a GC since the start; it's a conservative stop-the-world all-or-
nothing non-compacting mark-and-sweep garbage collector. Meaning:

1\. It can't tell the difference between a number on the heap that happens to
look like a reference to some active data, and an actual reference to some
active data. Hence it has to be conservative, and assume anything that looks
like a reference, is one. Rubinius has a precise GC, and so doesn't suffer
from this problem, which can lead to dead objects never being collected.

2\. The GC has to stop the VM while it's running. This is probably also the
case with Rubinius, however:

3\. It has to walk over every object in the VM in one go, so it gets
progressively slower the more objects you have. Rubinius has a generational
GC, where objects are split into pools based on how long they've been alive
for, and these can be scanned individually and at different rates appropriate
to their age (i.e. long-lived objects probably aren't worth checking very
often).

4\. It can't move objects around; when it frees something, it leaves a gap
where the object used to be. If a new object doesn't fit there, it has to go
somewhere else, wasting that space. In the long run this can lead to memory
fragmentation. Rubinius has a compacting GC, allowing it to fill in these
holes and make better use of memory, and also better use of CPU caches.

Yes, 1.9 compiles to bytecode, and yes in theory a JIT could be added to it,
but that's a pretty big project.

------
dublinclontarf
Not available on Windows yet, would be fun to have (to show others) but I
suppose if I'm going to use it for anything serious then it'll be on Linux.

------
rue
Hooray!

------
GrandMasterBirt
Cool. Is Rubinius faster than 1.8.6 or even 1.9? Was that the goal? Or is it
just a 1.0 milestone where the project is compatible enough to meet the 1.8.6
ruby language spec and native libs?

~~~
jon_dahl
The biggest goal, at least a few years ago, was to have a Ruby that is
substantially implemented in Ruby, as opposed to being a hundred thousand
lines of C under the hood. Paradoxically, this can result in speedups, since
it's easier to optimize expressive, well-written code. Avi Bryant gave a talk
at RailsConf a few years ago about how Smalltalk contains all the "features"
of Ruby that are usually blamed for its performance woes, but still managed to
be pretty fast. It's not the language features that keeps Ruby slow; it's the
opaque implementation.

~~~
nkassis
I think they are on the right track. Given that this is a 3 year old project,
I don't think we can compare it to smalltalk implementation with years of
development. I wonder how well it would compare to something like pypy and
other similar projects.

~~~
GrandMasterBirt
Better question: What happens if companies like google start eyeballing it and
putting some real money behind it.

~~~
jemfinch
You mean the same Google where Python beat Ruby years ago?

~~~
GrandMasterBirt
Can't blame them, even a year or two ago Ruby and RoR were much inferior to
today. And wait till RoR3 hits the shelves full steam. Granted I hope
ActiveRecord3 will include everything by default like DataMapper does but
whatever...

Ruby is still in infancy stages, Python is quite old. Hell Python was the
inspiration for Ruby.

I mean look at what is happening in the Javascript space. If Ruby and JRuby
implementations get really f-ing fast, we will get some major backings. The
problem is that instead of improving Ruby, Twitter decided to ditch it. Maybe
they really didn't have the people Google has when it comes to language
builders. Since google app engine runs python it is in direct google interest
to make it fast. Once it starts running ruby, vuala! So don't worry, they'll
get to it.

~~~
steveklabnik
> Granted I hope ActiveRecord3 will include everything by default like
> DataMapper does but whatever...

I'm not sure exactly what you mean by this, but Rails 3 will still be a full
stack framework. Something will be chosen for everything by default.

You'll be able to fully switch out ActiveRecord for DataMapper if you wish.

> Hell Python was the inspiration for Ruby.

I've never seen this before, usually I've heard Matz saying that it's Perl.
Maybe a typo?

~~~
jamesbritt
Matz has cited a number of inspirations, including Perl, Python, Lisp,
Smalltalk, Self (I think), and CLU.

He's also referred to Ruby as "Matz Lisp."

~~~
crazydiamond
> He's also referred to Ruby as "Matz Lisp."

So when does the "enlightenment experience" Eric Raymond promised come ? Or
did Matz take it all :-D

