Differences between Ruby and Python.

[Andrew Dalke]

Albert Wagner wrote:
> What's most significant, at the moment, is the number of
> c/c++ libraries that are available, with stable interfaces,
> for Python.  Presently, Ruby can't compare.

I see two problems with making Ruby's interfaces to existing
C libraries as wide ranging as Python's - gc finalization and
pthreads.

I've been curious about Ruby's garbage collection.  I know
it uses a "real" gc (in quotes since ref counting is a real
gc method, and the current ref counting + cycle detection is
even better).

I wrapped a C library for use with Python.  This library is
not friendly to automatic gc because it exposes all internal
pointers through opaque integer handles, starting with 1.

The ref counting semantics in CPython give me good assurances
of when I can delete an object.  In that way I can write my
code to call the library's dealloc functions as expected.  By
comparison, there is a JNI wrapped version of the C library for
Java.  My interface layer works, but leaks memory like crazy
under Jython because __del__ doesn't work the way I want it to.

As I understand it, Ruby also doesn't make that sort of
guarantee, which means I would need to do even more work to
ensure the library's dealloc calls occur in the right order.
Looking at http://www.rubycentral.com/book/ext_ruby.html it
can be done, but only at the C level, while I was able to
code all the dependencies I needed using pure Python.  (Again,
specific to the C implementation.)

I'm trying to figure out what rb_gc_mark does, but there are
only about 22 hits in Google and none of the ones in English
offer any detail.  It looks like I need to tell it which
pointers are relevant to a given object, but in my case those
are just integers.  I have no way to get access to the real
pointer.  I suppose I could just case the integer to a pointer,
but that won't work if there are two libraries using the same
opaqueness scheme.

Anyway, wouldn't this make it harder for Ruby to include
interfaces to some existing C/C++ code?  Or am I wrong on how
Ruby's gc interface works with native code?

Another problem I see deals with Ruby's use of its own thread
library instead of pthreads.  I know this makes the threading
more portable, but some of the libraries I know of can use
pthreads if available.  I worry about using two different
thread packages in the same system.

And remember, I am not a computer scientist nor do I play
a language designer on TV!

                    Andrew
                    dalke at acm.org