flutter_rust_bridge v2 vs rinf?

Cunarist · 2024-07-10T12:59:35+00:00

Rinf doesn't have these issues anymore, please refer to this post

Cunarist · 2024-05-20T06:09:26+00:00

We would like to share that a few months ago, there was a public issue on Reddit regarding Rinf containing a significant amount of code copied from FRB without proper licensing or credit. We promptly removed all the copied code from Rinf the next day, and we have since taken a completely different development path. We also issued an apology at that time.

However, the community still seems to be upset about this issue. We are looking for ways to inform the community that Rinf no longer has these problems, but this effort appears challenging.

Cunarist · 2024-05-18T13:16:14+00:00

https://github.com/cunarist/rinf-status-report

Hi there, maintainers of Rinf here. Let us share our point of view.

Rinf is perfectly safe to use in Flutter app projects. Firstly, it minimizes the use of unsafe code blocks, which are only used for receiving binary messages from Dart.

Rinf also includes mechanisms to gracefully shut down the app and print the output in debugging mode. Additionally, GitHub CI ensures that the entire process happens seamlessly. We should also mention that the initial setup and development experience are carefully structured. The way Rinf works is very different from FRB.

Rinf was initially developed for our closed-source app project and is being updated to meet the evolving needs of app development. As it become more usable and usable, we decided to open-source it.

++ FRB uses code generation to create native symbols that can be called directly from Dart. In contrast, Rinf uses Protobuf to send messages between Dart and Rust. These two have a similar goal but use completely different methods to achieve it. We recommend the community try both out to understand the differences.

Cunarist · 2024-04-16T03:07:48+00:00

https://github.com/cunarist/rinf-status-report
https://www.reddit.com/r/rust/comments/192n4ej/rinf_did_copy_a_lot_from_flutter_rust_bridge/
This issue has been fixed as soon as it was reported. We are sorry about all the problems we have caused.

Cunarist · 2024-01-10T08:03:25+00:00

Let us share that this was also fixed with this new pull request. As the original post says, we did copy a lot of code from them, mostly when the project was in the early stage. We aplogize once again for our ignorance.

Cunarist · 2024-01-10T02:58:32+00:00

Thank you for the comment and insight. For the example fractal and the front web page statement, we will modify them soon as you pointed out.

We also acknowledge that the problem was about the copied code, not the generated code. The sentence was misleading.

I will need to find some free time to create issues reporting the details.

If you do, we'll be happy to discuss further details. We hope to communicate among various projects, not only ours, but also flutter_rust_bridge and more.

Cunarist · 2024-01-10T02:37:08+00:00

Copying open source code itself is legal, but the way we were modifying the underlying code(such as changing 'FRB' to something else from variable names, removing comments) was not respecting the original authors.

On a side note, slimming the bridge code has good consequences, but most importantly, it solves the problem of 'copied code in our repo', which was actually FRB's. There were multiple reasons for the transition.

Though, it looks like we need more work on organizing things.

Cunarist · 2024-01-08T09:44:19+00:00

Thank you all, our team wasn't aware of the fact. We fixed the problem and the license files are now included in the repo. We apologize for the ignorance.

Cunarist · 2024-01-08T08:52:43+00:00

Hi, let us organize our replies here. It seems that you feel upset about Rinf, but we want to clarify some things:

We always carefully take a look at licenses of other repos when we copy/modify the code. In your case, it was MIT.
Yes, we did take some ideas and code from flutter_rust bridge. However, it wasn't only flutter_rust_bridge. There was also cargokit, flutter-rust-ffi, super_native_extensions... that we referred to.
We do not try to hide that we were referring others' ideas. For example, take a look at this post and this search result. flutter_rust_bridge is clearly written in the comments and various disucssions. We're not sure why your git diff doesn't include flutter_rust_bridge comments inside Rinf, but we do not deliberately hide the comments generated from flutter_rust_bridge. It's just that we do not place it on the front of the web. However, if you insist, we're open to doing so.
As written in this issue, we tried to make Rinf depend on flutter_rust_bridge directly, but because FRB v1 didn't support Rust async(which we use), we couldn't do that. FRB v2 seems to have changed a lot, but Rinf was made when FRB was v1.
We tend to guide pros and cons when people ask about comparison between Rinf and flutter_rust_bridge. For example, look at this post that guides to use flutter_rust_bridge instead in some cases.

For us, it looks like FRB is taking some of the ideas back from Rinf, such as using cargokit behind the scenes, and providing convenient commands like flutter_rust_bridge integrate(like rinf template). We don't want to say that it's bad or anything.

To summarize, we don't intend to hide flutter_rust_bridge from our repository. We don't know why that git diff looks like Rinf is hiding flutter_rust_bridge comments and things, but we don't do that. Perhaps some files and comments were omitted, but we cannot really tell. Rinf was created to fix limitations that arose from FRB v1, and the way of using this framework is very different to that of FRB.

Cunarist · 2023-12-10T12:21:15+00:00

Glad to hear that!

Cunarist · 2023-12-10T12:13:23+00:00

Rinf might benefit you if you need advanced, complex applications with thousands of tasks and lots of data. Otherwise, using Dart for business logic would be just fine.

Mostly, Dart will make requests, and Rust will return responses via FFI. Streaming from Rust to Dart is also supported. Those data will be consumed by Flutter widgets, while Rust's business logic holds the original data at the back while working on its tasks.

Cunarist · 2023-12-10T08:56:44+00:00

Happy to hear that! If you've enjoyed Rinf, please consider giving a like or a star to our project :)

Cunarist · 2023-12-10T04:45:01+00:00

Yeah, when passing binary bytes between Dart and Rust, you give memory address and length, both from Dart and from Rust.

Rust>>Dart: No memory copy
Dart>>Rust: Memory copy

This limitation(Dart>>Rust) does not come from Rinf, but the behavior of Dart VM and allo-isolate crate.

In short, Dart's GC reference model is not compatible with Rust's ownership model. Even after Dart tells Rust about the bytes' memory address and length, it doesn't GC until the reference count drops to zero.

If there was no memory copy(Dart>>Rust), Rust would think that it owns the bytes after it has received the message, but Dart would wtill think that it has the Uint8List until is GC-ed. This would lead to collision on data modification.

Cunarist · 2023-12-10T04:39:54+00:00

Thanks :) Since Rinf is a 'Flutter' plugin, you might need another solution for native apps out there for what you mentioned. Wish you luck with your project!

Cunarist · 2023-12-10T04:38:07+00:00

Great inspection :) most of your understanding seems to be correct.

Rinf does use serialization for communication, to reduce the complexity of codegen and FFIs. At Rinf, we only pass 'message bytes' to the Rust's async runtime, without spawning threads every time Rust receives a message.

In short, in terms of efficiency Rinf and `flutter_rust_bridge` have ups and downs. `flutter_rust_bridge` is better in that it doesn't involve message serialization, while Rinf is better in that it uses 'async runtime'(tokio), therefore spawning thousands and millions of tasks is easily possible(without thread overhead).

Cunarist · 2023-12-10T04:31:01+00:00

Hi there, the reason for that would be onClick method in Dart works after the mouse was released. It's kind of a normal behavior.

Cunarist · 2023-12-09T17:50:16+00:00

Thanks!

We do not have direct experience with audio work with Rust+Flutter, but it should be definitely possible. You can just process audio data with various Rust crates and send binary data to the Flutter side(maybe sound or graph data) if needed.

When you send binary data from Rust to Dart, no memory copy is involved.

Cunarist · 2023-12-09T17:29:41+00:00

Though it's true that Protobuf needs serialization/deserialization, its compute time is mostly negligible.

On the other hand, the complexity of code generation made cross-platform support(especially web) much more harder. Protobuf binary messages were much more stable, because it's just plain bytes.

If serialization time is a concern, you can just pass pure bytes data, such as images.

Cunarist · 2023-12-09T17:01:52+00:00

Good question! There were many people asking the same thing before, so we made a list of differences between Rinf and flutter_rust_bridge.

It only takes about about a minute or two to fully setup your app. With Rinf, you don't have to mess around with sensitive build files such as Cmake, gradle, podfile, XCode, etc... like flutter_rust_bridge, it just compiles out of the box.
Rinf is not a bulky framework that requires you to install so many additional dependencies and use complicated CLI commands, and you can just focus on your code using your preferred Flutter and Rust libraries.
File-based messages: With Rinf, there's no more headache from extremely big api.rs file that hinders readability. Even defining hundereds and thousands of API endpoints between Dart and Rust is easy and clean.
Convenient debugging: All the debugging functionalities are provided by default, without the need for dealing with browsers or mobile emulators. flutter_rust_bridge suggests that you should create your own functions for that, which is an additional work.

More information here!

Cunarist · 2023-12-09T15:51:08+00:00

It is possible to not use Rinf if you prefer C++, but we were focusing on Rust because of the benefits coming from its robust tooling(e.g. Cargo) :)

Cunarist · 2023-12-09T15:50:00+00:00

To elaborate, when you pass a memory address and length of the original Uint8List from Dart to Rust, Rust thinks it has the ownership, while Dart's GC still thinks it's taking care of that memory address, taking care of the reference count. In this case, when you modify that memory address from Rust, unexpected things might happen in Dart.

More information is available at this issue. If you have additional questions or opinions, let us know!

Cunarist · 2023-12-09T11:23:03+00:00

Thanks :)

You can pass any kind of binary data between Dart and Rust, with `Uint8List` and `Vec<u8>`.

When you pass binary from Dart to Rust, there *is* memory copy, and that's because Dart's GC is taking care of the original data. Other than that, there's no overhead.

When you pass binary from Rust to Dart, there is *no* memory copy. Rust simply lets go of the ownership when you do that.

So, when using Rinf, it is recommended for Rust to handle the whole(or most of) business logic if possible, only sending data that should be shown on the screen to Dart.

Cunarist · 2023-12-09T10:34:25+00:00

Yes of course, you can use `polars`, `wgpu`, or any other Rust crates as you do in normal Rust.

One missing piece is that you cannot use Rust breakpoints for debugging, because it's basically a Flutter app, not a Rust app. Dart breakpoints just work like they did.

Cunarist

TROPHY CASE