
The Challenge of Cross-Language Interoperability (2013) - mpweiher
https://queue.acm.org/detail.cfm?id=2543971
======
egypturnash
“We are sorry ...

... but we have temporarily restricted your access to the Digital Library.
Your activity appears to be coming from some type of automated process. To
ensure the availability of the Digital Library we can not allow these types of
requests to continue. The restriction will be removed automatically once this
activity stops.

We apologize for this inconvenience.”

Anyone else getting this?

If so, have a Wayback Machine link:
[http://web.archive.org/web/20180219210654/https://queue.acm....](http://web.archive.org/web/20180219210654/https://queue.acm.org/detail.cfm?id=2543971)

~~~
ScottBurson
I got that too, despite being already logged in to the site. I clicked on the
PDF logo in the upper right corner, though, and was served the paper. Some
bug, I guess.

------
nickpsecurity
A lot of this has to do with languages in no way designed for
interoperability. There have been platforms designed for cross-language
development.

OpenVMS standardized calling conventions for interoperability. CLR does that
at a VM level in low-level way. Ten15 on FLEX machine did it in high-level
way. Lots of variants of languages are targeting C, JVM, etc structured in
ways that make interoperability easier. Julia making using C and Python code
easy is an example. Finally, there's metaprogramming tools that make all the
languages DSL's interoperable via core language. Racket, Alan Kay's stuff, and
sklogic's tool cone to mind.

The ones having trouble are usually evolved away from cross-language
development with a lot of complexity that makes it harder than it already is.
Of course they're having to resort to things like ZeroMQ or whatever.

------
sjmulder
I'm on the lookout for a language that does a) not itself require a VM (can be
properly compiled) or significant runtime, but b) can be hosted in a VM
without too many leaky abstractions, and c) can interface well with other ABIs
and VMs.

C++ comes close (e.g. with Windows Runtime and Objective-C++) but its memory
model fails (b) and there are no type generators or such so you get a lot of
glue code generation.

A small Lisp dialect could easily be hosted in any VM and it can be made to
interface well with just about anything transparently (look at Racket's C
bindings) but the dialects I've seen fail (a) and lack lifecycle hooks that
would make building a C++0-like com_ptr<> type possible.

~~~
lmm
There's no standardisation of how to represent ownership across ABI boundaries
yet, and different languages' models are fundamentally incompatible: either
the VM/runtime expects to own all memory management (in which case interfacing
with another VM/runtime that follows the same model is virtually impossible)
or the programmer does it manually (perhaps with some help from the language
in the case of C++ or Rust). Embedding a language that does the latter in a VM
language is always going to involve fiddling with memory ownership in a
language unsuited to it (as you do when using SWIG or the like).

What are you actually trying to achieve here? If you're writing a library for
use from both VM and non-VM languages, you'll want your library functions to
have clear/simple memory ownership semantics anyway, and at that point any
unmanaged language will work reasonably well for you. If you just want your
library to be usable from several different styles of language, maybe a multi-
language VM will work for you.

~~~
sjmulder
I think templated or generic handle classes are pretty good for dealing with
foreign objects. They can handle any bookkeeping a VM requires.

The background is that I've been playing with C to write Win32 apps that are
highly backwards compatible (back to 3.11/Win32s if possible) but also modern
when running on newer Windows versions.

For the latter I've been manually writing COM exports which was painful but it
works. This made me consider C++ as an alternative where I'd be able to use
templated types (and destructors!) to great effect. I can limit my use of the
standard library to keep it freestanding.

However I would still be limited to writing native code, which is why I'd like
something that can target the Android Runtime and such.

~~~
lmm
> I think templated or generic handle classes are pretty good for dealing with
> foreign objects. They can handle any bookkeeping a VM requires.

What do you mean by this?

~~~
sjmulder
With C++' destructor call guarantee and its templating features, it's feasible
to implement shared_ptr-like types for foreign object types. Microsoft's
ComPtr for example takes care of COM referencing counting. If some VM would
require you to pin and unpin objects before and after use, you can do that in
such a handle.

~~~
lmm
Hmm, you're talking about calling _into_ a VM language from a manual-ownership
language like C++? At that point any VM language would be fine, but I'm not
sure that scenario makes sense in the first place - if the outer program is in
C++ that's presumably because it has some requirement avoid GC, and embedding
a VM that has to do GC would undermine that.

------
_pmf_
The Java ecosystem's JSR 223 is something to look at (at least for hosted
languages with a canonical object system).

~~~
merb
not as impressive as Graal.

~~~
mpweiher
Yes, sort of. Or maybe kind of not?

I am not sure I'd call what Graal is doing "interoperability", because you
essentially pull everything into that VM, instead of interoperating with it
where it is.

So they "interoperate" with C by making a C compiler that creates a Graal-
compatible AST, and as far as I can tell, the _only_ way of interoperating at
this point is creating a new Graal compiler.

~~~
Apanatshka
What I've gathered about Graal is that once you have a compiler for the
platform, Cross-Language communication on a hot path gets optimised to near-
zero cost.

~~~
mpweiher
Exactly. You're not really crossing boundaries any more, you just have
different surface-syntaxes for "the Graal language system".

