4 ms·

Tauri is such a breath of fresh air for a web developer like me! I picked up Rust because of it, and was easier than I thought (I've read lots of "Rust is hard"

Tauri is such a breath of fresh air for a web developer like me! I picked up Rust because of it, and was easier than I thought (I've read lots of "Rust is hard" articles). The application I wrote is a Hacker News client with focus on offline reading and listing comments in threads sorted by time and flat, instead of trees sorted by score (which incidentally, also works as a web application which is deployed here: https://ditzes.com/ https://ditzes.com/). I found it helpful when I'm traveling but still want to read discussions, useful for following along threads that are actively being discussed (this submission can be seen at https://ditzes.com/item/31764015 https://ditzes.com/item/31764015 for example) and also useful when using HN comments as reference to something I'm building. Guess I'm also pretty proud that the client is VERY fast, loading 1000 comments in something like 1s (because of the caching). Like this thread for the Coinbase layoffs: https://ditzes.com/item/31742590 https://ditzes.com/item/31742590 (1001 comments) The Tauri application currently works with 99% of the features of Ditzes, but the mouse "back" button doesn't actually navigate the internal browser back in history with Tauri yet, so I haven't done a "Show HN" yet as I consider that a essential feature of Ditzes (for following along threads via the "View" link) before "launching" it. The Tauri-part of the source can be found here: https://codeberg.org/ditzes/ditzes/src/branch/master/src-tauri https://codeberg.org/ditzes/ditzes/src/branch/master/src-tau... Overall, besides the extremely long compile times, Tauri has a been a pleasure to develop with, and I'd definitively use it over Electron in the future. Really looking forward to mobile support as well, as then I'll finally have a comfortable and offline-capable HN client for my cellphone.

microtonal 4y ago
Overall, besides the extremely long compile times Out of curiosity: fresh builds or also incremental builds? If the latter, how much of it is linking?
- capableweb 4y ago
  Both :) But what bothers me most, is the slow incremental debug builds. But that's a general Rust problem, although seems extra bad with Tauri. My project has ~1700 lines of Rust, ends up pulling in ~700 dependencies and changing one line in main.rs takes about ~20 seconds for the debug compile to finish (on a 5950X CPU). Fresh build takes about 1m30s but that only happens on CI, so not really a problem day-to-day for me. Full CI build on Codeberg/Woodpecker takes around 5 minutes from push to release created, but that's including other things too.
  - short_sells_poo 4y ago
    I wonder if there are any plans to buttress this issue with Rust. Last time I checked the issue was that there is/was no ABI stability which meant you couldn't have precompiled libraries to build against. The only way around it at the time was to expose C compatible APIs, but that means of course giving up much of Rust's strengths.
  - chrisandchris 4y ago
    > [...] My project has ~1700 lines of Rust, ends up pulling in ~700 dependencies [...] I have no experience with Rust. Having 0.4 dependencies per line (so every 3 lines you are dependent on a 3rd-party) sounds very extreme. Can you elaborate a bit what those dependencies are (like many std libs?)?
    - nicoburns 4y ago
      That will be including transitive dependencies. Consider how many dependencies making a HTTP request will pull in. Ones for network IO, ones for parsing HTTP request. Possibly separate ones for HTTP1, HTTP2, HTTP3. Ones for type definitions of HTTP requests. Rust convention is to publish these bits as separate crates even if they are published by the same maintainer(s) so as to improve compile times (separate crates can be compiled in parallel) and modularity (if you're writing a competing library then you can share the internals of the existing implementation when possible). This isn't like C++ where a single dependency is a huge project. Some crates are literally just trait (interface) definitions.
    - capableweb 4y ago
      You can see for yourself here: https://codeberg.org/ditzes/ditzes/src/branch/master/src-tauri/Cargo.toml https://codeberg.org/ditzes/ditzes/src/branch/master/src-tau... My project have ~30 dependencies defined for various features in the client. The rest are transitive. Here is the output of cargo tree for your leisure: https://pastebin.com/aep1bX4v https://pastebin.com/aep1bX4v A quick scan of cargo tree seems to indicate most of them comes from tauri and actix projects. Edit: oh, and also tantivy (a search engine) ends up pulling in ~300 dependencies which is a pretty big chunk of the total
stefanos82 4y ago
Do you use mold as your linker? If not, can you try using it and let us know whether it improves your compile times or not? Here's the instructions for using it with Rust: https://github.com/rui314/mold#how-to-use= https://github.com/rui314/mold#how-to-use=
- capableweb 4y ago
  Sure thing. Compiled mold from source and got the following numbers when compiling Ditzes: - Debug build from scratch: ~1m 20s - Incremental debug build: ~3s - Release build from scratch: ~3m 40s So, seems that helped quite a bit, thanks for the tip :) As someone who is generally unaware of things as I'm new to Rust, is there any drawbacks to using a non-default linker? Everything seems to work fine as far as I can tell, but no drawbacks mentioned in the repository of Meld makes me slightly skeptical.
  - nicoburns 4y ago
    The drawbacks of mold are: - It's linux only (macOS support WIP) - It's still somewhat experimental. It may not be able to link everything. There may be bugs. Having said that, it's written by someone with a lot of experience writing linkers (they previously worked on lld), can link codebases as complex as chromium, and generally seems to work well for most use cases. A common pattern would be to use mold for development, and then the regular linker (varies by platform) for release builds.
    - capableweb 4y ago
      > A common pattern would be to use mold for development, and then the regular linker (varies by platform) for release builds. That makes a lot of sense. Thanks for sharing the potential drawbacks and possible solutions to those :)

microtonal 4y ago

Overall, besides the extremely long compile times Out of curiosity: fresh builds or also incremental builds? If the latter, how much of it is linking?

capableweb 4y ago
Both :) But what bothers me most, is the slow incremental debug builds. But that's a general Rust problem, although seems extra bad with Tauri. My project has ~1700 lines of Rust, ends up pulling in ~700 dependencies and changing one line in main.rs takes about ~20 seconds for the debug compile to finish (on a 5950X CPU). Fresh build takes about 1m30s but that only happens on CI, so not really a problem day-to-day for me. Full CI build on Codeberg/Woodpecker takes around 5 minutes from push to release created, but that's including other things too.
- short_sells_poo 4y ago
  I wonder if there are any plans to buttress this issue with Rust. Last time I checked the issue was that there is/was no ABI stability which meant you couldn't have precompiled libraries to build against. The only way around it at the time was to expose C compatible APIs, but that means of course giving up much of Rust's strengths.
- chrisandchris 4y ago
  > [...] My project has ~1700 lines of Rust, ends up pulling in ~700 dependencies [...] I have no experience with Rust. Having 0.4 dependencies per line (so every 3 lines you are dependent on a 3rd-party) sounds very extreme. Can you elaborate a bit what those dependencies are (like many std libs?)?
  - nicoburns 4y ago
    That will be including transitive dependencies. Consider how many dependencies making a HTTP request will pull in. Ones for network IO, ones for parsing HTTP request. Possibly separate ones for HTTP1, HTTP2, HTTP3. Ones for type definitions of HTTP requests. Rust convention is to publish these bits as separate crates even if they are published by the same maintainer(s) so as to improve compile times (separate crates can be compiled in parallel) and modularity (if you're writing a competing library then you can share the internals of the existing implementation when possible). This isn't like C++ where a single dependency is a huge project. Some crates are literally just trait (interface) definitions.
  - capableweb 4y ago
    You can see for yourself here: https://codeberg.org/ditzes/ditzes/src/branch/master/src-tauri/Cargo.toml https://codeberg.org/ditzes/ditzes/src/branch/master/src-tau... My project have ~30 dependencies defined for various features in the client. The rest are transitive. Here is the output of cargo tree for your leisure: https://pastebin.com/aep1bX4v https://pastebin.com/aep1bX4v A quick scan of cargo tree seems to indicate most of them comes from tauri and actix projects. Edit: oh, and also tantivy (a search engine) ends up pulling in ~300 dependencies which is a pretty big chunk of the total

stefanos82 4y ago

Do you use mold as your linker? If not, can you try using it and let us know whether it improves your compile times or not? Here's the instructions for using it with Rust: https://github.com/rui314/mold#how-to-use= https://github.com/rui314/mold#how-to-use=

capableweb 4y ago
Sure thing. Compiled mold from source and got the following numbers when compiling Ditzes: - Debug build from scratch: ~1m 20s - Incremental debug build: ~3s - Release build from scratch: ~3m 40s So, seems that helped quite a bit, thanks for the tip :) As someone who is generally unaware of things as I'm new to Rust, is there any drawbacks to using a non-default linker? Everything seems to work fine as far as I can tell, but no drawbacks mentioned in the repository of Meld makes me slightly skeptical.
- nicoburns 4y ago
  The drawbacks of mold are: - It's linux only (macOS support WIP) - It's still somewhat experimental. It may not be able to link everything. There may be bugs. Having said that, it's written by someone with a lot of experience writing linkers (they previously worked on lld), can link codebases as complex as chromium, and generally seems to work well for most use cases. A common pattern would be to use mold for development, and then the regular linker (varies by platform) for release builds.
  - capableweb 4y ago
    > A common pattern would be to use mold for development, and then the regular linker (varies by platform) for release builds. That makes a lot of sense. Thanks for sharing the potential drawbacks and possible solutions to those :)