Collaborating on more languages support

[Jauler]

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

[mhammond]

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.

[Jauler]

Thanks for the info, this clarifies everything we needed to know :) and now the approach is clear :).

[arg0d]

C# bindings generator is available at https://github.com/NordSecurity/uniffi-bindgen-cs

Feel free to leave some feedback :)

[roeierez]

@arg0d this is great work, we in Breez are going to try this soon and let you know how it goes.
BTW do you plan to work on golang binding as well?

[Jauler]

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:

https://github.com/NordSecurity/uniffi-bindgen-go

[roeierez]

@Jauler Amazing. We already integrated C# succesfully and we are going to give this a try as well.

[mhammond]

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.

[badboy]

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

[caesay]

Just coming here to add, of the "third party" generators which currently exist, none of them have ended up being very well supported.

They all seem to lack important features like custom types, withforeign, async, (even when the underlying language does support those things) - and additionally, many of them are not even maintained at all. Of the ones linked from the readme, none of them appear to support these features or have been updated to the latest versions. Additionally, many of these other generators have had to fork this repo to get things working, and that's a huge hassle for generator maintainers (probably contributing to the lack of maintenance). Another issue this has created is needing to install many different CLI tools (one per language) just to generate bindings for one project.

I understand the position taken in 2022 (not wanting the added maintenance overhead while uniffi was evolving) but hope that this stance might change in 2025+. The only way we'll truly be able to rely on uniffi for any language is if it is included and tested against changes in the main repo here. I assume that each language is essentially just a text template of some kind, and once they are initially written it should be fairly low effort / straightforward to keep them up to date with things.

I would be willing to help out with PRs writing/improving bindings for languages I need, as some others have also been, but I'm not willing to spin out forks etc. If changes are required to uniffi core to support more languages, I think they should be adopted here.

[mhammond]

Speaking personally, I don't really see this stance changing - the people maintaining the core repo simply don't have the skills or knowledge to maintain these other languages. There might be a misconception about the complexity here - adding support for the things you mentioned (async, foreign traits, etc) are certainly not straightforward.

I know some bindings have "vendored" uniffi, but I'm not aware of them forking. We'd certainly be open to addressing whatever needs they have to avoid this.

Have you tried collaborating with the maintainers of those bindings?

[arg0d]

The current situation is easily explained by looking at the needs of project maintainers. mozilla/uniffi-rs care about Swift/Kotlin. NordSecurity/uniffi-* projects additionally care about C#/Go/C++. I'm assuming Mozilla projects don't use these other languages, so they aren't going to allocate any significant effort to support those other lanugages. NordSecurity projects have less of a priority on bindings generation, so we've have been piggy backing on the work done by Mozilla, while attempting to fill the missing gaps (C#/Go/C++). The current state of C#/Go/C++ projects has been mostly sufficient for us, there hasn't been a strong enough need to spend effort maintaining version parity with mozilla/uniffi-rs.

I'm hearing about some plans at our department to update C#/Go/C++ generators to work with latest mozilla/uniffi-rs version, so you can expect some action in the coming week/months.