Collaborating on more languages support
Jauler opened this issue · comments
Hi,
Thanks for creating such an amazing project and making it open source.
At NordVPN we do have some similarities in terms of using rust libraries for some of the common logic and then integrating them into multitude of applications written in "foreign" languages. We have looked a little bit into UniFFI project and we really liked what we found, You guys have this FFI generation problem solved very nicely. And we would really like to upgrade our own solution. The only problem is that we are providing libraries for these four languages:
- Kotlin ✔️
- Swift ✔️
- go ➖
- C# ➖
(yeah, it is all over the place... 🙄 ), anyway, of course, I am not coming here to ask for more languages support and that's it, rather seeking consultation on how best to collaborate, if we can. We have seen this and this issues and we fully understand Your concerns about maintaining additional languages. But we are willing to contribute generators for golang and C# languages and if the full solution works for our internal use-cases, maintain those generators from time to time to keep up with the core. Unfortunately we cannot promise very fast reaction time, but we would like to keep up-to-date in case we are using UniFFI to generate bindings and willing to dedicate time for that.
But we are not sure how best to approach this and whether this really makes sense for You. What would be Your thoughts?
┆Issue is synchronized with this Jira Task
┆friendlyId: UNIFFI-203
Hi - thanks for your interest and nice comments about UniFFI - I hope it continues to meet your needs.
The short story here is that we are trying to better support having bindings implemented in external crates rather than being maintained here. There are a number of reasons for this, including the fact that we would prefer to avoid blessing any particular set of bindings for any particular language, and even recognize that in some cases it might make sense to have multiple bindings for a single language, each with a different implementation strategy (eg, javascript bindings for use inside a browser are likely to be different from javascript bindings used within node). #1200 discusses moving the Ruby bindings out of this crate and a case could be made that all language bindings should live externally, but there's not much appetite for moving the languages used in production by Mozilla at this time.
There's more information in #1241 and the issues linked from there, and while we do need those better docs, this should be largely supported now - we have already implemented JS bindings for use inside Firefox and these live in the main Firefox repository and not here (#1241 as a link to that).
tl;dr - we'd love to see you implement bindings for these languages, but would strongly encourage you to maintain them externally and would be happy to help iron out any bumps you find trying to do that.
Thanks for the info, this clarifies everything we needed to know :) and now the approach is clear :).
C# bindings generator is available at https://github.com/NordSecurity/uniffi-bindgen-cs
Feel free to leave some feedback :)
Hey ho,
We have just opened up the golang bindings. It is a very very first release, so keep it in mind, but any feedback is welcome:
@Jauler Amazing. We already integrated C# succesfully and we are going to give this a try as well.
Fantastic - congrats! It would be great if you'd like to put a PR up to reference these in https://mozilla.github.io/uniffi-rs/Overview.html with whatever attributions and/or warnings you desire.
Fantastic - congrats! It would be great if you'd like to put a PR up to reference these in mozilla.github.io/uniffi-rs/Overview.html with whatever attributions and/or warnings you desire.
We have a list in the readme as well: https://github.com/mozilla/uniffi-rs#external-resources