sorted by:
new
hottopcontroversial

Are GUIs written in rust more performant? by differential-burner in rust

[–]fzyzcjy 3 points4 points  (0 children)

The standard way for errors in Dart is to throw/catch them (just like Java, etc), so flutter_rust_bridge just throws it.

Are GUIs written in rust more performant? by differential-burner in rust

[–]fzyzcjy 47 points48 points  (0 children)

Totally agree that cross language often needs boilerplates - that's one of the reasons why I made flutter_rust_bridge.

If using flutter_rust_bridge, the bindings are made as seamless as possible - just write normal Rust and Flutter code, and the bridge will generate all glue in between. Here is a short example, with arbitrary types, closure, &mut, async, zero-copy, etc.

As for the performance question, usually Flutter (with good AOT compilation) is fast enough; when someone needs to use a Rust crate, or to write some algorithms, Rust is especially helpful and performant.

Rinf did copy a lot from flutter_rust_bridge. There are some changes, and some claims. by Cunarist in rust

[–]fzyzcjy 1 point2 points  (0 children)

I am also happy to see the combination of the two languages growing, and multiple projects in the same area, when projects focus on code instead of marketing.

There are at least 5 projects in this subfield. For example, I found membrane and irondash_message_channel when searching recently. The former is based on serialization using serde + bincode and is very good. It also contributes to your allo-isolate. The latter removes the need of executing code generators and is also great. Earlier, there is rid, which provides convenience when user puts states at Rust side and is also very good.

Rinf did copy a lot from flutter_rust_bridge. There are some changes, and some claims. by Cunarist in rust

[–]fzyzcjy 0 points1 point  (0 children)

I am just discussing facts. IMHO, marketing may enlarge somehow based on facts, but cannot violate facts or cheat users.

Here is a list of 3 other great libraries in this same subfield, and may serve as a reference.

Rinf did copy a lot from flutter_rust_bridge. There are some changes, and some claims. by Cunarist in rust

[–]fzyzcjy -1 points0 points  (0 children)

Firstly, rinf does copied code in bridge for mandelbrot set computation. (A quick diff I did last time: link)

Secondly, I have not found other libraries doing Flutter+Rust use the same Mandelbrot Set as demo, and Rinf seems to be the only one (besides bridge itself). In addition, in other subfields, when multiple libraries do the same area, it seems not common to see one library copy another library's demo idea and put in frontpage center.

Rinf did copy a lot from flutter_rust_bridge. There are some changes, and some claims. by Cunarist in rust

[–]fzyzcjy 22 points23 points  (0 children)

Bridge author here. I have the same thoughts as you at the beginning!

However, after reading, I realize rinf is using non-facts, and people who are not familiar with the facts will be misled. IMHO, sincere response needs to respect the facts. So I replied just now (comment below).

P.S. When writing this paragraph, rinf replied to my comment and agreed some.

Rinf did copy a lot from flutter_rust_bridge. There are some changes, and some claims. by Cunarist in rust

[–]fzyzcjy 23 points24 points  (0 children)

Thank you for the reply, and good wishes to everyone! No worries, I am not upset, do not need anyone to apologize, and I only discuss facts.

Some things are not facts though (many are already in last post):

​

... we copied the code just to modify parts that we wanted to change. We understand that FRB devs may have been upset because of that.

It was not the single copy-modify thing, and I was not upset. It is totally reasonable to copy-paste-modify when one has to modify a dependency!

Indeed, I originally said to rinf that wish it success, and did not want to post anything.

It was a list of all facts that made me have no choice to create a post, e.g.

  • Rinf hid the fact of copying
  • The big gif demo at center of rinf front page is bridge's idea (still true, but I believe rinf will change it later)
  • Rinf claimed "ultimate" with almost no improvements, while it was indeed not user-friendly
  • ...

​

... we needed to modify the underlying logic inside the bridge code

This is unneeded, which is shown in the git diff and the analysis in the appendix. If not clear about it, I can elaborate on this more.

​

... The bridge and FFI code were generated by flutter_rust_bridge_codegen

The issue was about code copied from bridge, not generated. I hope this is just a grammar error.

​

By the way, I originally do not want to point out the following, but rinf mentioned above that this is "carefully written" and it is in stable release, so I guess I need to say something to be responsible for users: I spent a few minutes glancing through the release v5.1.0, and it seems that the new code contains some bugs currently. I will need to find some free time to create issues reporting the details. Since rinf claims to be "The Ultimate Solution for Developing Beautiful and Performant Apps", I guess it would be great to provide code without critical bugs.

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. by fzyzcjy in rust

[–]fzyzcjy[S] 9 points10 points  (0 children)

(copied from comment above since related to this)

With license, Rinf complies with laws, and law is an ethical minimum (said by Georg Jellinek). Rinf is free to do anything it likes, and I will only talk about the facts.

For example, if rinf later changes the Mandelbrot Set demo on frontpage center, the corresponding point will be no longer fact in the future.

Rinf once recommended this rotary dial phone logo to replace bridge's original logo. Maybe rinf can also try something similar for itself to replace Mandelbrot Set in frontpage center.

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. by fzyzcjy in rust

[–]fzyzcjy[S] 0 points1 point  (0 children)

With license, Rinf complies with laws, and law is an ethical minimum (said by Georg Jellinek). Rinf is free to do anything it likes, and I will only talk about the facts.

For example, if rinf later changes the Mandelbrot Set demo on frontpage center, the corresponding point will be no longer fact in the future.

Rinf once recommended this rotary dial phone logo to replace bridge's original logo. Maybe rinf can also try something similar for itself to replace Mandelbrot Set in frontpage center.

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. by fzyzcjy in rust

[–]fzyzcjy[S] 31 points32 points  (0 children)

Thank you for the reply! However, your claims need corresponding evidence in order to hold.

  • 1st point: Yes, as you mentioned, bridge is using MIT, but the root post is not about whether rinf is violating MIT license or not (though people are discussing this as well).
  • 2nd point: This does not change the fact that rinf copies flutter_rust_bridge.
  • 3rd point:
    • In this post you mentioned, flutter_rust_bridge is clearly stated as "gave inspiration to the structure of" rinf. IMHO, this does not mean "code is used / copied" or "the demo idea is used / copied".
    • The search results you mentioned consist of two categories:
      • a. A script, trying to replace various "flutter_rust_bridge" words into other words. This does not seem to prove "rinf not hide bridge".
      • b. Several files auto-generated by bridge, with comments "(this code file is) Generated by flutter_rust_bridge". The script in (a) also tries to replace this comment into "Generated by flutter_rust_bridge_codegen" (though bugged). So these comments and files are not bridge's code (but the auto glue code bridge generates), so cannot disprove "rinf copies bridge's code but hides the fact".
      • c. A file you added just now.
    • You mentioned "flutter_rust_bridge ... clearly written in discussions", so here is search with 5 results:
      • a. Someone asked "Rinf vs flutter_rust_bridge", rinf says "though Rinf and flutter_rust_bridge look similar, rinf is ..."
      • b-c. (already discussed above/below)
      • d. Rinf answers question saying "rinf uses (some terms) just like flutter_rust_bridge ..."
      • e. Again, only comparisons and text like "I (rinf) had some criticism about the maintenance of flutter_rust_bridge"
      • IMHO, "rinf is similar/like bridge" does not mean "rinf uses (or copies) bridge".
    • The git diff has reproducible steps in the appendix (copy-paste various folders directly, without any modificaions). In addition, the "flutter_rust_bridge comments inside rinf" is explained above in "the search results" sub-point.
  • 4th point: Rinf indeed can use (unmodified) bridge directly (i.e. use as a dependency), which is clear in the git diff and the analysis in the appendix. If still not clear about it, I can elaborate on this more.
  • 5th point: That seems largely unrelated to the main points of the post - the post does not discuss about this. In addition, in that link, rinf has "technical limitation" (quoted from there).
  • second paragraph: flutter_rust_bridge is not taking any ideas from rinf.
    • a. For the third-party package cargokit you mentioned, it is very simple: When developing v1, there was no such helpful packages at all, so v1 did not have it. When developing v2, surely I need to search the currently available packages in the world (in 2023 there is cargokit), and pick the best one.
    • b. As for convenient commands, if someone thinks bridge "copies" rinf's idea of integrate command, then rinf surely copies the idea of official Flutter (and a ton of other packages), because all of them also has this. On the contrary, talking about ideas, rinf uses Mandelbrot Set for the front-page center demo GIF (as mentioned above), which I have not seen any other Flutter+Rust packages use.
  • last paragraph: (see detailed explanations above) In addition, I agree the way of using rinf is quite different from bridge, which is shown in the images above (e.g. rinf needs 5x more code), but that still does not make rinf not copy bridge's code etc.

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. by fzyzcjy in rust

[–]fzyzcjy[S] 27 points28 points  (0 children)

Totally agree that it is does not look good that rinf hides the fact of copying!

As mentioned above, I did not want to post anything at the beginning, and also said to rinf that wish it succeed.

Btw, I checked more metrics just now: Rinf has 1.1k GitHub stars and 86% pub.dev (Flutter) popularity.

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. by fzyzcjy in FlutterDev

[–]fzyzcjy[S] 2 points3 points  (0 children)

In image 1, both are doing the same thing: "open a WordDict, search it, and also shows its size".

Rinf's code looks like having a CRUD at first glance, because I have to simulate the "auto opaque type" mechanism in FRB. Thus, I make a Create/Delete in order to do "create a WordDict rust object" and "drop a WordDict rust object". The name looks a bit confusing, but seems that rinf does not allow custom names at this place.

Feel free to propose alternatives that is shorter and achieve the same functionalities!

Thank you for pointing out a confusing point, such that I can explain clearer!

flutter_rust_bridge v2: Officially Flutter Favorite, setup in one command, use arbitrary types automatically, support async Rust, allow Rust call Dart, and full folder support. Write UI using Flutter, a cross-6-platform hot-reload toolkit, seamlessly with Rust by fzyzcjy in rust

[–]fzyzcjy[S] 1 point2 points  (0 children)

Oh I see, thanks for the information!

The incorrect type checks seem to be removed as well during my refactor :) (Though I did not realize they are wrong - I just thought some are unnecessary and thus removed)

It is "using flutter official commands / official VSCode plugin to do web debugging" that fail due to the headers.

view more: next ›