Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rubinius 1.0 (Fabius) Released

rubini.us

Post reply on HN
Print view View original

31–40 of 50 posts

Re: Rubinius 1.0 (Fabius) Released

#31

Post by daveungerer »

telemachos wrote: post #30
bruceba wrote: post #8

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.

Here's Wayne Seguin's take on Rubinius (he's the developer behind rvm, and he puts it nicely, I think): Rubinius is a ruby interpreter written in C++ using many advanced techniques and technologies such as LLVM, a "precise, compacting, generational garbage collector", a compatible C extension api to standard MRI Ruby and many other awesome ideas that will give any language nut a huge nerdon. (from http://rvm.beginres…

Actually, his take on it isn't quite accurate. It's not "written in C++".

From http://rubini.us :

Wherever possible Rubinius is written in Ruby. Where not possible (yet), it's C++.

And further down:

The Rubinius bytecode virtual machine is written in C++, incorporating LLVM to compile bytecode to machine code at runtime. The bytecode compiler and vast majority of the core classes are written in pure Ruby.

So, it's the VM that's C++. The bytecode compiler (which is technically what's meant by "interpreter" in this case) is ruby.

Re: Rubinius 1.0 (Fabius) Released

#32

Post by evanphx »

daveungerer wrote: post #31
telemachos wrote: post #30

Earlier quoted context omitted.

Here's Wayne Seguin's take on Rubinius (he's the developer behind rvm, and he puts it nicely, I think): Rubinius is a ruby interpreter written in C++ using many advanced techniques and technologies such as LLVM, a "precise, compacting, generational garbage collector", a compatible C extension api to standard MRI Ruby and many other awesome ideas that will give any language nut a huge nerdon. (from http://rvm.beginres…

Actually, his take on it isn't quite accurate. It's not "written in C++". From http://rubini.us : Wherever possible Rubinius is written in Ruby. Where not possible (yet), it's C++. And further down: The Rubinius bytecode virtual machine is written in C++, incorporating LLVM to compile bytecode to machine code at runtime. The bytecode compiler and vast majority of the core classes are written in pure Ruby. So, it's th…

Well, not exactly. The interpreter is in C++. By bytecode compiler he means the code that translates from a ruby AST into bytecode, which is in ruby.

Re: Rubinius 1.0 (Fabius) Released

#33

Post by petercooper »

evanphx wrote: post #25
wavesplash wrote: post #18

Earlier quoted context omitted.

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…

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!

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 ;-)

Re: Rubinius 1.0 (Fabius) Released

#34

Post by kemiller »

evanphx wrote: post #6
sreque wrote: post #5

Earlier quoted context omitted.

I just did a quick test of 1.9 vs rubinius on the alioth pidigits and btrees benchmarks, and rubinius was 1.5 times as slow on pidigits and twice as slow on btrees. In addition, the release notes state that they are aware that several string operations in Rubinius are currently slower than their MRI 1.8 equivalents. I'm excited that rubinius is out, but I'm not sure at the moment what it's advantages are versus MRI i…

This seems pretty accurate given the kind of performance we've seen thus far. One thing to understand about Rubinius is that we've optimized it to the hilt for running Ruby code. So when you see Rubinius performing, say, 1.5x slower than MRI on a particular String method, what you're seeing is Rubinius running ruby at 1.5x slower than C code. If you compare Rubinius to MRI both running pure ruby code, you'll see Rubi…

Hi Evan,

This is perhaps a silly question, but now that you have a solid base of ruby-in-ruby is there any room to re-optimize certain critical sections (hashes, sockets...) in C? Perhaps using a custom API that preserves most or all of the flexibility that is Rubinius's hallmark?

I presume that since you still support most compiled gems that linking to C code is still possible. Just wondering if there might be a best-of-both-worlds solution out there.

Re: Rubinius 1.0 (Fabius) Released

#36

Post by evanphx »

kemiller wrote: post #34
evanphx wrote: post #6

Earlier quoted context omitted.

This seems pretty accurate given the kind of performance we've seen thus far. One thing to understand about Rubinius is that we've optimized it to the hilt for running Ruby code. So when you see Rubinius performing, say, 1.5x slower than MRI on a particular String method, what you're seeing is Rubinius running ruby at 1.5x slower than C code. If you compare Rubinius to MRI both running pure ruby code, you'll see Rubi…

Hi Evan, This is perhaps a silly question, but now that you have a solid base of ruby-in-ruby is there any room to re-optimize certain critical sections (hashes, sockets...) in C? Perhaps using a custom API that preserves most or all of the flexibility that is Rubinius's hallmark? I presume that since you still support most compiled gems that linking to C code is still possible. Just wondering if there might be a bes…

We already done that, optimize out certain things into primitives, which are implemented in C++.

We support as subset of the MRI extension API, mainly we don't support anything using RBASIC(), RHASH(), or RREGXP() because those expose raw C data structures and we don't use the same data structures as MRI.

Re: Rubinius 1.0 (Fabius) Released

#37

Post by GrandMasterBirt »

jemfinch wrote: post #26
GrandMasterBirt wrote: post #13

Earlier quoted context omitted.

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

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

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.

Re: Rubinius 1.0 (Fabius) Released

#38

Post by steveklabnik »

GrandMasterBirt wrote: post #37
jemfinch wrote: post #26

Earlier quoted context omitted.

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

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…

> 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?

Re: Rubinius 1.0 (Fabius) Released

#39

Post by jamesbritt »

steveklabnik wrote: post #38
GrandMasterBirt wrote: post #37

Earlier quoted context omitted.

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…

> 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 Mat…

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."

Post reply on HN