From: Aaron Patterson <aaron@...>
Date: 2010-01-26T04:31:19+09:00
Subject: Re: ruby bounties--list of bounties

On Tue, Jan 26, 2010 at 04:17:32AM +0900, Chuck Remes wrote:
> 
> On Jan 25, 2010, at 1:12 PM, Mike Dalessio wrote:
> 
> > On Mon, Jan 25, 2010 at 1:12 PM, Charles Oliver Nutter
> > <headius@headius.com>wrote:
> > 
> >> On Mon, Jan 25, 2010 at 6:25 PM, Mike Dalessio <mike.dalessio@gmail.com>
> >> wrote:
> >>> Charlie, you're making a great case against using FFI.
> >> 
> >> FFI is much better than writing any C code at all, due to the
> >> security, stability, and portability problems of writing your own C
> >> bindings. If you are permitted to load a given library and that
> >> library is available and you *must* use that library, FFI is the only
> >> logical choice. But it doesn't get around the fact that you need the
> >> library you're binding to be available and loadable on your target
> >> platform. FFI > C bindings, but [platform-independent binary] > FFI.
> >> And that usually means Java-based.
> >> 
> >> I should also point out that you don't necessarily have to write JVM
> >> libraries in Java; you could also use Scala or Fan or similar
> >> languages, and it would be just as portable (albeit a bit larger due
> >> to the runtime dependency on those languages' runtime libraries).
> >> 
> >> But yes, at the end of the day, I believe writing stuff in a portable
> >> binary format like JVM bytecode (or CLR bytecode) is a better choice
> >> than writing in a language that has to be recompiled for every target
> >> system. You ought to know that already...would I be working on JRuby
> >> if I believed any differently? :)
> >> 
> > 
> > I agree with everything you're saying, more or less.
> > 
> > However, none of that relates at all to what I think is the crux of the
> > issue, which is that everyone writing a non-pure-Ruby gem today is forced to
> > choose one of these options:
> > 
> > 1) Support nearly everyone by maintaining two ports of your code: FFI for
> > JRuby; C for MRI, Rubinius and MacRuby. Don't support GAE.
> > 2) Support everyone by maintaining two ports of your code: JVM for JRuby and
> > GAE; C for MRI, Rubinius and MacRuby.
> > 3) Maintain only a single port, FFI, and force everyone on MRI to take a
> > performance hit of some kind. Oh, and don't support Rubinius, MacRuby or
> > GAE.
> > 4) Don't support JRuby or GAE. Just write it in C.
> > 5) Don't support MRI, Rubinius, or MacRuby. Just write it for the JVM.
> 
> FFI originated with rubinius, so I would wager that it will work once the FFI APIs get synched up again. Also, MacRuby has FFI support on its roadmap. That changes your picture a bit.

Rubinius implements enough of the MRI C api that it will run Nokogiri
today.  MacRuby will follow suit, and I expect that to happen sooner
than it supports FFI (though this is conjecture).  With minor tweaks to your C
code, you can have a native extension that runs on all three *today*.

-- 
Aaron Patterson
http://tenderlovemaking.com/