Mike Hearn wrote:
- Bindings to the core libraries for accessing things like
GFS/BigTable and doing RPCs: optional but the utility of any language
that can't use them is limited. C++ compatibility would certainly
make this easier but SWIG integration would make it even easier
still, as we already have SWIG set up for Python. Figuring out an
easy way to integrate the garbage collected world with the manually
managed world is also a trick. I presume the Python bindings already
figured this out but it'd obviously be nice if the bindings could be
as thin as possible.
Of all those, the last would be the most work. The google "standard
library" is a huge collection of robust and well written code -
everything from well known stuff like BigTable down to custom
threading and malloc libraries. The nice things D brings to the table
can't compensate for the loss of that codebase. I haven't tried
binding stuff into D, although given that it's got some C/C++
compatibility it's way ahead of Python and Java already.
Of course, D has direct access to any and all C code, being binary
compatible with the C ABI. D, in fact, relies on being linked with the
standard C runtime library and startup code.
D2 has limited access to the C++ ABI:
. name mangling (i.e. global function overloading)
. single inheritance classes
. binary compatibility with C++ function calling conventions
I don't know the ABI for the Google libraries, but this should help.
Mixing D's gc world with manually managed memory isn't hard, as long as
the following rules are followed:
1. don't allocate in one language and expect to free in another
2. keep a 'root' to all gc allocated data in the D side of the fence
(otherwise it may get collected)
