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.

Complicated? Yes. I've summed it all up in a nice matrix here:
http://gist.github.com/286126

I personally think these choices all suck, and I refuse to paint a happy
face on any of them.

We chose option 1 for Nokogiri (you're welcome, intarnets), but everyone
who's writing a gem today has to make this decision for themselves.

My point is that any of these choices contains a tradeoff, and stating that
one in particular "hurts" people more than another is just disingenuous. I'd
rather help people understand the tradeoffs.