Rinf copies a lot from flutter_rust_bridge, but hides the fact, says bridge is bad and rinf is ultimate. I have no choice but to post this.

206 points fzyzcjy

Hi!

The majority of rinf's code is copied from flutter\_rust\_bridge, and it uses bridge's idea for homepage center demo. However, rinf seems to not want to tell people it uses bridge, says that bridge is bad and rinf is "the ultimate solution". Nevertheless, rinf is not user-friendly, and there is a comparison below.

I originally said to rinf that wish it success, and did not want to post anything. However, rinf then claimed "ultimate" with almost no improvements, and also hid the fact of copying. I always thought open source is that people help each other and work hard together. If everyone is doing like rinf, nobody will be able to find and use any hard-working packages. Thus, I have no choice but to create this post.

Details:

Rinf copy-pasted bridge's source code, with modifications as follows: Delete comments mentioning bridge, change a bit of logic that does not need to be changed here, and rename things, etc (details in appendix). Rinf uses bridge to do generation during development, and most code are bridge's when running rinf.

As for the big gif demo at center of rinf front page (website \[1\], GitHub \[2\]), it is bridge's idea - using mathematical Mandelbrot Set to illustrate algorithms in Rust and UI in Flutter. As we know, anything using Flutter+Rust can be a demo here. Among the countless possibilities, two libraries choose the same. The probability seems quite low.

However, rinf seems to not want people to know the fact that rinf copies bridge a lot. On one hand, rinf only says bridge "gave inspiration to the structure of" rinf \[3\]. On the other hand, when mentioning bridge (e.g. \[4\], \[5\], \[6\]), rinf does not mention it uses bridge. This seems different from the behaviors of open source libraries I usually see.

Rinf says bridge is bad (same link as above), but this is because rinf was originally a high-level wrapper of bridge. This is common in open-source (e.g. autocxx vs cxx). I chose to do nothing inside bridge, though having that in mind for a long time, otherwise rinf would be more or less useless. Recently, since rinf moves away from bridge, I am free to implement whatever I want.

Rinf claims to be "the ultimate solution for developing beautiful and performant apps" \[1\]. However, rinf is indeed not user-friendly, which is shown below.

On one hand, compared with other libraries, rinf seems to not be the "ultimate" it claims to users. For example, to implement the rinf tutorial task, rinf requires users to write more than twice amount of code than bridge. As another instance, for the typical scenario "state" which users asked in both libraries, rinf needs >5x more code than bridge, and also need more complex logic. (details in image 1 and appendix)

On the other hand, compared with rinf itself, if rinf writes a bit more code, it will be much more convenient for users. For example, considering the official rinf example again, users could have written less than half amount of code using slightly updated rinf vs original rinf. (details in image 2 and appendix)

Appendix(https://github.com/fzyzcjy/appendix\_2024): It contains text and code that are too long to be put here, as well as links \[1\]-\[6\].

https://preview.redd.it/30v66r7wu4bc1.png?width=1820&format=png&auto=webp&s=6a15d281ed20497010733b7502055a46c35372aa

https://preview.redd.it/ws3mfq7wu4bc1.png?width=1180&format=png&auto=webp&s=437053f9cbd540ab9012caf741b19236bc41dbfa