Go: A new system programing language

[Walter Bright]

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)