From: Charles Oliver Nutter Date: 2010-01-26T17:07:03+09:00 Subject: Re: ruby bounties--list of bounties On Mon, Jan 25, 2010 at 8:12 PM, Mike Dalessio 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