3 ms·

> even as a fulltime Rust developer, I don't really see the advantage of using Rust for it vs, say, TypeScript. UI libraries aside, Rust is better language and

> even as a fulltime Rust developer, I don't really see the advantage of using Rust for it vs, say, TypeScript. UI libraries aside, Rust is better language and has better tooling, which overall contributes to productivity. TS/JS as a language for tooling is brittle and slugish (unless it's rewritten in Rust, where significant amount of tools is already heading), and I am happy for it to be replaced.

raincole 3y ago
> UI libraries aside I mean the rest of your comment may be 100% correct but we could stop reading at this point. Obviously the biggest pain point of Rust GUI app development is UI library.
- fiedzia 3y ago
  True, it will take time. Tauri/Dioxus and others are still new and far from being mature. If you want to deliver project right now, Rust is not there, but moving in the right direction quickly.
jeroenhd 3y ago
Normally I agree with you on the tooling issue for JS/TS, but just look at the boilerplate you need for this Rust tool. I think it's very close in terms of obscure config files and tooling, complete with multi step build and generation processes. I think Rust isn't a great frontend language for mobile platforms. Mobile applications are full of weak references because of how they can be unloaded or cached at any moment when the user switches to another application. The native APIs dance around this issue, but Rust can't. Of course you can use weak reference in Rust, but I find that this leads to very ugly code full of macros that aren't very Rust looking.
- fiedzia 3y ago
  Boilerplate and process: This in part is a matter of tooling maturity and can easily be solved, and in part will be hidden in some github action, so I am not bothered (as long as solution is maintained). With amount popularity Rust tools have and increasing amount of money invested, I am not concerned here. As for macros - yes, you will have them. Doesn't seem to be any more special than react or any other js framework where some magic is performed for you.

raincole 3y ago

> UI libraries aside I mean the rest of your comment may be 100% correct but we could stop reading at this point. Obviously the biggest pain point of Rust GUI app development is UI library.

fiedzia 3y ago
True, it will take time. Tauri/Dioxus and others are still new and far from being mature. If you want to deliver project right now, Rust is not there, but moving in the right direction quickly.

jeroenhd 3y ago

Normally I agree with you on the tooling issue for JS/TS, but just look at the boilerplate you need for this Rust tool. I think it's very close in terms of obscure config files and tooling, complete with multi step build and generation processes. I think Rust isn't a great frontend language for mobile platforms. Mobile applications are full of weak references because of how they can be unloaded or cached at any moment when the user switches to another application. The native APIs dance around this issue, but Rust can't. Of course you can use weak reference in Rust, but I find that this leads to very ugly code full of macros that aren't very Rust looking.

fiedzia 3y ago
Boilerplate and process: This in part is a matter of tooling maturity and can easily be solved, and in part will be hidden in some github action, so I am not bothered (as long as solution is maintained). With amount popularity Rust tools have and increasing amount of money invested, I am not concerned here. As for macros - yes, you will have them. Doesn't seem to be any more special than react or any other js framework where some magic is performed for you.