Question: are there any plans to add more languages?

[saks]

Hello everyone!

I love uniffi-rs and was following this project for a long time. Thank you so much for your wonderful work!

I was wondering if I can use uniffi-rs to generate ruby library in addition to swift and kotlin. While experimenting I have reached the point where the generated ruby code is good enough as a direct replacement to my FFI layer that was written by hand.

Would this project be interested in having a ruby adapter?

┆Issue is synchronized with this Jira Task
┆Issue Number: UNIFFI-52

[bendk]

@saks thanks for the love! I think we're open to new adapters, but can't commit to maintaining the code. Do you want to open a PR for someone to look at?

[saks]

Thank you @bendk! Here it is #436 :)

[rfk]

Hi @saks, I haven't had a chance to look at your PR in any detail yet, but I wanted to say a quick thanks for your interest and for diving in here!

Short-term, it seems tractable for additional language bindings to be maintained in this repo on a best-effort basis. We currently have a gecko_js backend in the tree here that isn't actively kept up to date and it's been manageable so far. We also don't have any production consumers for the python backend yet.

Longer-term, I'd like to explore ways for individual language bindings to be maintained independently of this repo, both to let people experiment with things more easily, and to avoid extra maintenance burden on the core repo itself. I don't really know that that looks like yet, but I'd be interested in your thoughts on whether and how it might work.

For example, you can imagine us adding a convention similar to how custom cargo commands work, where there could be a separate uniffi-bindgen-ruby crate that knows how to turn our abstract ComponentInterface definition into Ruby code, but can be maintained and released on its own independent cadence. I'm sure there would be some complexity there, but my gut feeling is that it would make a better overall developer experience. (Questions about Ruby bindings aside, I would very much like the gecko_js backend to be able to live somewhere in mozilla-central rather than here in Github, because it will be of no value to any code that doesn't also live in mozilla-central, and it would be much easier to test it as part of the mozilla-central build process).

[saks]

Hi @rfk, thanks for looking into this! I like the idea of different language adapter to live in their own repo, this will definitely simplify maintenance for the core of uniffi.

Short-term, it seems tractable for additional language bindings to be maintained in this repo on a best-effort basis.

Right now my main focus is to bridge the gap between mobile platforms and a server side. Going forward I'm happy to do my best to maintain ruby bindings :)

Longer-term, I'd like to explore ways for individual language bindings to be maintained independently of this repo, both to let people experiment with things more easily, and to avoid extra maintenance burden on the core repo itself. I don't really know that that looks like yet, but I'd be interested in your thoughts on whether and how it might work.

Sounds like a good idea. I believe this architecture can add a bit of complexity in order to establish a protocol which language adapters can use to generate code based on ComponentInterface but it's worth the effort 👍

We also don't have any production consumers for the python backend yet.

I see. I'm curious about swift and kotlin,README states that "This is all very experimental and incomplete..." From your perspective, is it still the case for a code generated for mobile platforms?

[saks]

Also, have you considered a feasibility of adding a WASM adapter of some kind?

[rfk]

I'm curious about swift and kotlin,README states that "This is all very experimental and incomplete..."
From your perspective, is it still the case for a code generated for mobile platforms?

Ah yes, sorry, the readme is due for a refresh - we now have production apps shipping using swift and kotlin bindings generated from this tool (specifically, some of the shared components used by Firefox for Android and Firefox for iOS) so while the "incomplete" part is still accurate, the "very experimental" part can probably be softened a bit.

have you considered a feasibility of adding a WASM adapter of some kind?

Heh, I have a lot of thoughts on WASM, thanks for asking!

The initial data model here was inspired by the work on WASM Interface Types, although both have evolved significantly since then. In a possible future world, I can imagine the tooling here being a very thin layer on top of WASM, perhaps something along the lines of:

• Instead of compiling the Rust code into a cdylib, you compile it into a .wasm file with WASM Interface Types definitions to describe the high-level consumer API.
• Instead of having tooling to read our custom .udl interface definition and generate Kotlin, Swift, etc, we have tooling that can ahead-of-time compile a .wasm file into a native module that can be loaded from Kotlin, Swift, etc, using the WASM Interface Types info to generate the high-level consumer API.

I think such a world would be pretty amazing - you could write language bindings based on a shared spec rather than coupling them to the particular details of UniFFI, and you could use them with languages other than Rust that also happen to compile to WASM.

Of course that world doesn't exist yet, and we need to ship things in the meantime, so UniFFI does its own thing and I try to keep an eye on the evolution of the WASM ecosystem, and look for opportunities to build in that direction.

For example: if we do end up introducing some sort of intermediate format so that language bindings generates can be maintained independently of the core crate, maybe that format can be a subset/superset of the WASM interface types proposal, so that the Kotlin/Swift/Ruby generators be kind of prototypes for a future more general wasm-to-X compilation toolchain.

That's all very hand-wavy of course, but it's on my mind.

If you're happy to share, I'm curious to hear how you would see WASM fitting in to your own picture of how you'd like to use UniFFI.

[saks]

Ah yes, sorry, the readme is due for a refresh

Thanks @rfk :) No worries, I had an impression that kotlin/swift part is well polished since I've been following how application-services repo adopts uniffi and it doesn't look like something very experimental 👍

Heh, I have a lot of thoughts on WASM, thanks for asking!

I deeply agree that this future world is truly amazing, hopefully more people working on programming languages will see the value of interoperability. Thank you so much for sharing your vision and insights into potential WASM usage.

If you're happy to share, I'm curious to hear how you would see WASM fitting in to your own picture of how you'd like to use UniFFI.

Pretty happy to share, but my use case is pretty trivial. Right now I expose a rust library to browser JS using wasm-bindgen (the same library that I expose to ruby/kotlin/swift). This works but I quickly found too much of a code that can easily be generated. I haven't spent much time thinking through is it even possible to implement JS adapter through WASM right now, but happy to explore it later if you see a potential :)

[rfk]

I haven't spent much time thinking through is it even possible to implement JS adapter through WASM right now,
but happy to explore it later if you see a potential

I haven't thought deeply about this, but it does seem like the sort of thing that should be possible, and would be fun to explore :-)

[rfk]

Longer-term, I'd like to explore ways for individual language bindings to be maintained independently of this repo

I was reminded that we already have an issue on file to discuss this, #299. I've written out some more concrete thoughts in #299 (comment) and any feedback is welcome!

[stan-irl]

If you're happy to share, I'm curious to hear how you would see WASM fitting in to your own picture of how you'd like to use UniFFI.

FWIW I've just found my way here looking for a rust equivalent of Djinni to write a shared metrics library that will run on ios, android and Web. I think this usecase is pretty common for a lot of companies that are shipping a mobile app and website or electron app.

I'm working at a company that doesn't have any cpp devs so trying to use something like Djinni is unrealistic and will no doubt result in bad cpp code but I think it's feasible for the team to pickup rust given how strict the compiler is. UniFFI would be perfect for this usecase if it supported WASM with js/ts bindings