diplomat
marker
diplomat | marker | |
---|---|---|
6 | 2 | |
452 | 138 | |
3.1% | 1.4% | |
8.8 | 9.4 | |
3 days ago | 4 months ago | |
Rust | Rust | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 or later |
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.
diplomat
-
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.
-
ICU4X 1.2: Now With Text Segmentation and More on Low-Resource Devices
I don't think that accurately describes what ICU4X does. It generates code directly in the language needed using Diplomat. Which currently supports JS/TS/Wasm, C, C++, and .NET, but we plan to support more (Dart is actively being worked on, there is a lot of interest in Java). Diplomat is designed to be relatively easy to write backends for: you have to write code that converts its internal IR to bindings code, so you mostly need to understand that internal IR and figure out how to idiomatically map it to other languages.
- 1Password releases Typeshare, the "ultimate tool for synchronizing your type definitions between Rust and other languages for seamless FFI"
-
Multi-language library support: Is it possible?
The ICU4X team is developing diplomat - https://github.com/rust-diplomat/diplomat/
-
Anyone interested in open-sourcing high-level memory-safe bindgen for Dart/Flutter <–> Rust?
I'm not that interested in a separate tool for this but it would be really cool to have a dart plugin as a part of Diplomat. Diplomat's not fully polished yet but it's totally okay to add new language backends to it. (Eventually I plan to restructure it so that it has a cleaner plugin interface, but for now "checked into tree" is fine for backends)
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.
What are some alternatives?
uniffi-rs - a multi-language bindings generator for rust
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.
cbindgen - A project for generating C bindings from Rust code
bifrost
wgpu - Cross-platform, safe, pure-rust graphics api.
serde-reflection - Rust libraries and tools to help with interoperability and testing of serialization formats based on Serde.
moat - mobile type (currently Swift, Kotlin) generation from Haskell types
stklr - STKLR is a tool to help you automatically link up named stuff in your rust docs!
airbax - Exception tracking from Elixir to Airbrake
design