On Mon, Jan 25, 2010 at 8:12 PM, Mike Dalessio <mike.dalessio / gmail.com> wrote:
> 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.

Yeah, I agree all the choices have various levels of suck. Being a JVM
guy I'd love to just tell everyone to "write it in Java", since
there's practically no cross-platform challenges in that case (and
don't anyone start telling me about how bad some Swing app is at
working across platforms; you're digging in the wrong place and the
JVM has a stellar cross-platform record when it comes to plain old
libraries). But that obviously doesn't solve the larger problem of
writing extensions or binding libraries in ways that all Ruby
implementations can support.

I'm nothing if I'm not pragmatic. I fully recognize that FFI is a real
pain in the ass to wire up for anything nontrivial, especially if you
have the issues Aaron talked about with struct layout and memory
management, and I sympathize. I'm also extremely grateful to all the
library authors who have swallowed that pill in order to support
JRuby. We're ready and willing to find ways to support extension
writers better, be it through ffi-inliner, a safe C API subset, or
simply helping to find maintainers for JVM-based (i.e. no native code)
ports of key libraries.

And to Aaron: I do apologize for being so gruff about id2ref. We'd had
it disabled on master for several months without any reports of
trouble; Nokogiri just ended up being the first lucky customer.
Hopefully you've been able to find a better way, like maintaining your
own table or using the WeakHash that Evan mocked up. If not, I stand
ready to help find another solution.

- Charlie