[int_19h]

C ABI is very limiting, though, and it's a pain to implement.

What's really needed is some standard higher-level ABI (that does things like classes in a sane way), but which is made out of the existing C ABI building blocks in a manner that allows any existing language with C FFI use it. We can then add a new FFI layer that maps higher-level concepts better, but everyone can still play regardless.

This is exactly what COM was, and what its current evolution, WinRT, is. Any language that can do C structs and function pointers can ultimately do COM/WinRT, but it establishes things like lifetime semantics (refcounting), runtime metadata API, standardized futures etc on top of that. Then languages take that and map it to things that make sense there.

But it needs to be a shared public spec, preferably standardized.

[cryptarch]

... so, a C-ABI + per-language wrappers, or perhaps a high-quality cross-platform, multi-language wrapper generator? That effectively accomplishes what you're describing in your second paragraph.

Either way, it'd be great if one could implement efficient GUI's (and full apps more generally) on Android in C/C++/Go/Rust without having to generate JVM bytecode on the fly (or like Xamarin does: at compile time).

[int_19h]

A language wrapper generator is about right, although for some languages it makes more sense to wrap things dynamically rather than generate code. .NET does it for WinRT, for example.

The problem with conventional C ABI is that it's just too low-level to produce good wrappers. I mean, all you have are global functions, structs, and data and function pointers. There isn't even a standard string type! (you can say char*, but there's the need to deal with lifetime issues - who deallocates what).

So in practice you need the C ABI, plus all those conventions, like how an "object" looks (i.e. how you do things like method dispatch or type queries), how a callback looks, how strings work etc. And all those conventions are expressed in terms of that basic C ABI - but they also have to be standardized, and they become ABI of their own, like COM and WinRT.

And you also need a convention/standard for metadata, for those wrappers to consume, and for any sort of runtime magic like property bindings - like typelibs for COM and metadata assemblies for WinRT.