uniffi-rs VS flume

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)

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?

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)

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.

Mozilla's uniffi-rs is really good. You write a common IDL and the bindings are generated automatically.

https://github.com/mozilla/uniffi-rs

At Mozilla we built a multi-language bindings generator: https://github.com/mozilla/uniffi-rs/

Is there a connection with Mozilla UniFFI ?

Rust <> Swift/ Kotlin works very well with uniffi-rs by Mozilla: https://github.com/mozilla/uniffi-rs

The repository seems abandoned; or maybe complete?

At work we use flume, which is another capable multi-producer, multi-consumer async-capable channel [1]. It's great for shuffling data between threads, as well as between async tasks, and between threads and async tasks. Basically any time you want to pieces of code to exchange data or signals without pesky shared state.

1: https://github.com/zesterer/flume

I also like flume, it has impressive performance (although not the best). More importantly, it's written only with safe rust. https://github.com/zesterer/flume

The most commonly suggested replacement for mspc is crossbeam-channel; flume is also relatively popular.

It's not officially deprecated, but the alternatives on crates.io are considered better. flume and crossbeam-channel feature less unsafe code and offer better performance. Benchmarks.

it's slow (checkout flume's benchmarks for example)

I would have done the same. I think, and I might be wrong, but the only other alternative, besides anything unsafe, would be to pass mutex back, but I am not sure this would be faster. Btw, I have not done testing, but you might want to look at Flume for your mpsc channels: https://github.com/zesterer/flume Flume, seems to be very fast mpsc implementation. I am planning to evaluate it for logging system.

For concurrency/parallelism, you launch at most 2 * CPU Cores, PIN them and use a fast broker to spread the task (like a ring buffer or an MPSC). But you keep linear scan, tight loops, SIMD friendly data, on each. You are not switching context that much, and instead, bet you will process the batch fast. (CPUs are fast today!)

https://crates.io/crates/flume and https://crates.io/crates/crossbeam-channel provide MPMC channels.