> what you're attributing to the runtime (memory-model et al) is part of the abstract machine specified by the language's semantics
OK, I see where you're going with this. But now you'll need a "bottom representation", which, even if it is easier to transform than machine instructions, will be pretty hard to decompile to another language. For example, most interesting lock-free algorithms require some sort of garbage collection; how do you describe that GC behavior, which doesn't necessarily need to be general purpose, in a way that can be ported to both C and Go?)
Theoretically it may be doable, but in practice the problem is very, very hard.
The big question, then, is why bother? The JVM already provides excellent interoperation with excellent performance that can cover the vast majority of (at least) server-side applications out there, and Graal/Truffle are extending the range of languages that the JVM can provide the fastest implementation for (it's early days and it's already pretty much on par with V8 when running JS, and faster than PyPy for Python). Those applications not within this profile range will use other languages (like C++), but those languages are already more expensive to develop in, and their developers happily pay more for more specialized algorithm implementations.
> Shared-memory cross-runtime distribution works too.
That's true (provided both sides can agree on an ownership and concurrency behavior).
OK, I see where you're going with this. But now you'll need a "bottom representation", which, even if it is easier to transform than machine instructions, will be pretty hard to decompile to another language. For example, most interesting lock-free algorithms require some sort of garbage collection; how do you describe that GC behavior, which doesn't necessarily need to be general purpose, in a way that can be ported to both C and Go?) Theoretically it may be doable, but in practice the problem is very, very hard.
The big question, then, is why bother? The JVM already provides excellent interoperation with excellent performance that can cover the vast majority of (at least) server-side applications out there, and Graal/Truffle are extending the range of languages that the JVM can provide the fastest implementation for (it's early days and it's already pretty much on par with V8 when running JS, and faster than PyPy for Python). Those applications not within this profile range will use other languages (like C++), but those languages are already more expensive to develop in, and their developers happily pay more for more specialized algorithm implementations.
> Shared-memory cross-runtime distribution works too.
That's true (provided both sides can agree on an ownership and concurrency behavior).