marker
uniffi-rs
Our great sponsors
marker | uniffi-rs | |
---|---|---|
2 | 26 | |
137 | 2,278 | |
1.5% | 5.0% | |
9.4 | 9.5 | |
4 months ago | 7 days ago | |
Rust | Rust | |
GNU General Public License v3.0 or later | Mozilla Public License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
marker
-
Blog Post: Next Rust Compiler
Check out this, which aims to implement said stable interface!
-
1Password releases Typeshare, the "ultimate tool for synchronizing your type definitions between Rust and other languages for seamless FFI"
Hey, I might be able to give some input how I deal with it in [rust-linting](https://github.com/rust-linting/rust-linting). For some context, the project needs to load several dynamic libraries and provide each of them with an abstract syntax tree. Serializing and deserializing the types for every step would most likely be too expensive. That's why I opted for a Rust <-> Rust FFI. There are two parts of this: 1. The loaded libraries needed to accept data from a driver. For this, I generate functions in the library crates which are marked as `extern "C"` and only use FFI safe types. Passing information to the loaded crates then always calls the generated functions, which intern call access a thread local struct instance in the dynamic crate. It's important that the instance implement a specific trait. For the library creation, it seems like magic. 2. Callbacks. The loaded libraries need to pass information back to the driver. For this, I use a struct with function pointers. These are also marked as `extern "C"` and need to only use FFI safe types. The definition of FFI safe, is a bit difficult. Slices, `str`, `Option<>` and most of the rusts STD types don't have a stable layout to the point, that it can change between compilations with the same compiler. Therefore, it's required that each passed type is `#[repr(C)]`. Options are wrapped in an enum, which has `#[repr(C)]`, slices and strings are dismantled into a data pointer and a length. On the receiving and they're reconstructed again. A small warning. I'm not an expert on FFI interfaces. My implementation would probably have some problems with lifetimes, if I'd use a slightly different memory model. So far, this has worked well (Besides the required boilerplate). The project is currently sadly lacking documentation, as it's still under heavy development. If you want, feel free to lock around the code base. The stable types and most of the interface is inside the `linter_api` crate.
uniffi-rs
-
Opaque Types for UniFFI
On my youtube series "Growing up Rust", I'm building a personal CRM in Rust with a Swift frontend. I'm using CQRS and an event-driven architecture with the least amount of swift as possible. I'm using UniFFI to generate the bindings for swift (and in this example python)
-
Willow Protocol
Not officially. We currently have bindings for rust, python, golang and swift.
These were the most asked for bindings (python for ml, golang for networking and swift for ios apps).
We are using uniffi https://mozilla.github.io/uniffi-rs/
Would you need C or C++ bindings?
- UniFFI: Automatically generate foreign-language bindings for Rust libraries
- Compiling Rust for .NET, using only tea and stubbornness
-
Show HN: Pip Imports in Deno
An alternative is metacall. The example in the readme is about calling Python from Javascript, but it also works with other languages, like Ruby, C#, Java, and other languages
https://github.com/metacall/core
List of supported languages here https://github.com/metacall/core/blob/develop/docs/README.md...
In the future, maybe webidl (or extensions of it) will bring interoperability between languages too. At the moment there is https://mozilla.github.io/uniffi-rs/ for interoperability between Rust and a number of languages (basically the ones mozilla needs: Swift, Kotlin, Javascript)
-
ffizz: Build a Beautiful C API in Rust
The tooling for the first kind -- calling Rust from another language -- is a bit less developed, and tends to rely on code generation that doesn't necessarily produce a natural C API. cbindgen, uniffi, cxx, and Diplomat all take this course.
-
macOS Apps in Rust
Mozilla's uniffi-rs is really good. You write a common IDL and the bindings are generated automatically.
https://github.com/mozilla/uniffi-rs
-
Write SDK “base” in Rust, wrap in other languages?
At Mozilla we built a multi-language bindings generator: https://github.com/mozilla/uniffi-rs/
-
An experiment in the Rust compiler to begin devising a new cross-language ABI that's higher-level than the C ABI, with the goal of safer and easier FFI
Is there a connection with Mozilla UniFFI ?
-
Tauri now supports Android/iOS in the 2.0 branch!
Rust <> Swift/ Kotlin works very well with uniffi-rs by Mozilla: https://github.com/mozilla/uniffi-rs
What are some alternatives?
rfcs - RFC process for Bytecode Alliance projects
flutter_rust_bridge - Flutter/Dart <-> Rust binding generator, feature-rich, but seamless and simple.
reduze - Zig program reduction is upstream in compiler due to various parser + formatter interactions.
rust-android-gradle
bifrost
PyO3 - Rust bindings for the Python interpreter
serde-reflection - Rust libraries and tools to help with interoperability and testing of serialization formats based on Serde.
cxx - Safe interop between Rust and C++
stklr - STKLR is a tool to help you automatically link up named stuff in your rust docs!
wasmer-go - 🐹🕸️ WebAssembly runtime for Go
design
glommio - Glommio is a thread-per-core crate that makes writing highly parallel asynchronous applications in a thread-per-core architecture easier for rustaceans.