From: Charles Oliver Nutter <charles.nutter@...>
Date: 2009-02-03T18:22:09+09:00
Subject: Re: Native gem roundup!

Brian Candler wrote:
>> * They are wrappers around a C API/library, as in zlib, rmagick, 
>> nokogiri
>> * They are written for performance reasons, to implement a particular
>> algorithm in a native language or call a library for the same reasons
> 
> * They interact directly with the Ruby interpreter (e.g. rcov, 
> ruby-debug)

Damn good point...you totally trumped me there. So there's three cases, 
with this new one perhaps being truly the most impl-specific case.

> Here's the set on my home machine:
> 
> $ cd /usr/local/lib/ruby/gems/1.8/gems/; find . -name '*.so'
> ./json-1.1.3/ext/json/ext/parser/parser.so
> ./json-1.1.3/ext/json/ext/generator/generator.so
> ./json-1.1.3/ext/json/ext/parser.so
> ./json-1.1.3/ext/json/ext/generator.so

Do people generally use the native json gem for performance reasons? 
Does a pure-ruby version not cut it? Are there benchmarks?

> ./fastthread-1.0.1/ext/fastthread/fastthread.so
> ./fastthread-1.0.1/lib/fastthread.so

Ok, not needed under JRuby, recent Ruby 1.8.6 or 1.8.7+.

> ./rcov-0.8.1.2.0/lib/rcovrt.so
> ./rcov-0.8.1.2.0/ext/rcovrt/rcovrt.so

Tooling...blasted tooling. JVM has so much good tooling, if I could only 
harness it well for Ruby stuff.

> ./linecache-0.43/ext/trace_nums.so
> ./linecache-0.43/lib/trace_nums.so
> ./mongrel-1.1.5/ext/http11/http11.so
> ./mongrel-1.1.5/lib/http11.so
> ./sqlite3-ruby-1.2.4/ext/sqlite3_api/sqlite3_api.so
> ./sqlite3-ruby-1.2.4/lib/sqlite3_api.so
> ./ruby-debug-base-0.10.3/ext/win32/ruby_debug.so
> ./ruby-debug-base-0.10.3/ext/ruby_debug.so
> ./ruby-debug-base-0.10.3/lib/ruby_debug.so
> ./ruby-gpgme-1.0.3/lib/gpgme_n.so
> ./ruby-gpgme-1.0.3/gpgme_n.so
> 
> On another machine I also have termios, rubywmq, ruby-postgres, 
> sys-filesystem, RedCloth

Thanks for the response. Obviously I'm interested because of JRuby, and 
I think most of these have equivalents already, but there are obviously 
gaps. I think dev-time tooling may actually be where we're weakest at 
the moment, which is ironic given the history of JVM/Java-based tooling.

- Charlie