The Dioxus's founder wrote this nice article: Notion – The all-in-one workspace for your notes, tasks, wikis, and databases..
Since the compilation times are the first (and maybe the only one) issue I'm having with Rust,
I would like to know if something has been done, especially about:
Putting it all together - Compile times
Between incremental linking, a parallel frontend, macro expansion caching, release mode-macros, and precompiled binaries, I’m positive we could cut Rust compile times by 90% or more. None of these steps are impossible, but they need dedicated engineers backed by a substantial amount of funding.
A ton was done about compilation times. But Rust makes it trivially easy to blow up your compilation times arbitrarily high. Throw in a few proc macros which block, done. Or write a long-running build script.
"macro expansion caching" - macros are not sandboxed. There is no way to reasonably cache their expansion without either breaking non-idempotent macros (like diesel's SQL schema validation), or redesigning them to provide such static guarantees.
"a parallel frontend" - easier said than done. Work on the parallel frontend has been going on for close to 10 years.
"incremental linking" - that's not even a language problem. Also incremental linking doesn't help in any way with clean builds, and linking time isn't a major time sink for most projects anyway.
"precompiled binaries" - like those that C++ has for all 4 decades of its existence? Compile times are still through the roof. Turns out splitting a project into precompilable binaries isn't easy, and comes with many major downsides, like ABI break issues.
Rust's compile times are generally in the same ballpark as for C++. Win some, lose some, depending on the specifics of individual projects. Rust has better modularity, C++ has better parallelizability. "I’m positive we could cut Rust compile times by 90% or more. None of these steps are impossible, but they need dedicated engineers backed by a substantial amount of funding." - how "substantial" are we talking about, exactly? Hundreds of millions of dollars were poured into improving compile times for C++, and it's still a pain.
7 Likes
I would like to point out that the notation that diesels macros cannot be cached because the depend on external states is mostly wrong. There is only a single macro in diesel, which depends on an external state and that's diesel_migrations::embed_migrations!() which reads files from the hard this. All other macros do only depend on the tokens passed to the proc-macro and are perfectly cacheable. For the embed_migrations!() macro: It's waiting on a stable API to read directories from the hard this, which in theory is also an operation that's perfectly fine to cache if the underlying proc_macro crate would allow to register that dependency as state.
2 Likes