Comment by lmm | Hacker News Reader

Comment by lmm | Hacker News Reader

Parent Full thread

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.

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.

> 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?

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.

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.

You are badly conflating some issues here. How to implement automatic memory management is a runtime design issue. How to enforce proper non-memory resource management is a language design issue. Nothing forbids an implementation of a safe-Rust-like language with a garbage collector. Destructors would still be called deterministically, and destructed objects would still be unusable afterwards, as mandated by the language's semantics. But memory will only be reclaimed during the next garbage collection cycle.

There are other (better!) reasons against cross-language interoperability, though, such as the reduction in static guarantees to an unusable lowest common denominator.

Reply on news.ycombinator.com