Rust support

[canatella]

Imported from #53

Is there some interest in adding Rust support ? I have some part of my C++ code bases that I'd like to migrate to Rust and I think that Djinni and its interfaces would make a good and easy target for interop. What do you think ?

Just some random idea, I'm not an expert in Djinni and even less in Rust but maybe first adding a C generator that creates an FFI api. Then use that code to present the C++ implementation to the equivalent Rust interface and vice-versa. There is the problem of somehow respecting the std::shared_ptr<> lifetimes and probably a tons of other things I did not think about but I just want to spark a discussion and check for interest in this feature.

[canatella]

I was thinking again about this lately, and another question I have is what should we be able to do with Rust. I don't know how the Python bindings works, but when multiple language are supported on the same platform, should each language be able to talk to each other ? As of know in Java for example you can call C++ and C++ can call Java. Does the Python implementation support calling both Java and C++ or just C++ ? Should a Rust binding be able to call/be called from every language ? I guess that would be possible by always going through C++: Java -> C++ -> Rust and C++ -> Rust. I should have a look at the Python bindings to see what they are actually doing ;)

[a4z]

The idea is not that all languages can talk to each other, for something like that you would use a messaging system to send messages from the Java process to the Python process and the Rust process and back, for example.

The djinni idea, and problem it solves is, that you share code between that languages.
You have for example C++ code that encodes/decodes data. Now you can use that C++ code from any language that has djinni bindings, and you do not reimplement it again.

[canatella]

I completely understand that, I have a reasonable code base using djinni for a few years already, but my idea here would be to migrate some of my C++ code to Rust, for that I'd need Java and ObjC to call into rust code instead of C++. The Rust code should be able to call into the C++ code and possibly the other way around. I guess that we could keep using C++ as the main interface but allow for a Rust implementation, that's why I said Java -> C++ -> Rust.

[a4z]

As in #53 mentioned, Python uses FFI. So for FFI the same code could be an option.

The C binding currently run just under the Python name, but we will extract that in future.

Of course, since you use the C Interface, live time handling has to be taken care for in the implemented language, in the djinni generated code of the target language.
Djinni generates Python, or Java / Objective-C code, that handles such things, and users do use that generated code, so for users it just works.

[canatella]

Here is an interesting project that does that: https://cxx.rs/ by using a Rust dsl to provide definition of the C++ interface and macros that generates Rust and C++ glue code, kind of the same way as Djinni does but using Rust macros. I should definitively have a look at that. Adding a generator to Djinni to generate the Rust idl should be straight forward as a first step, even though djinni should probably be able to generate the glue code directly.

[epicstar]

Seeing how Rust has become viable for cross-platform code, I would 100% support this idea to have the option to use either Rust or C++ as the cross-platform code implementation. I haven't coded in Rust before, but I do plan to use Rust cross-platform for a future project and would love to volunteer.

[a4z]

As written above, the way is to utilize the C bindings.
They exist and work (kind of) for Python, so they could be generalized for other languages as well.

However, this would require active developers, and they do not exist.
My goal was never to add new features but to keep the current state usable and maintained. So djinni users get bug fixes or adoptions to new SDK/NDK platforms. This goal was and is reached.

But for other activities to happen, active people are needed. And since they are rare, I have no huge hope that will happen.
Please note that dropping a feature and then disappearing and letting others maintain the new code is not active development.
We got features added over time that are now basically unmaintained. (C# and Python bindings). So from now on I am very cautious about what to add to the existing code base since every addition makes it more expensive to maintain the project. And this project maintenance is a 100% spare time activity.

However, if you seriously can picture volunteering over time, you are very much welcome to do so!