> Rust’s compile times are crippling
It's kind of a meme here on HN but while Rust compilation times are indeed higher than I wished they were, calling them “crippling” is a massive exaggeration.
My daily driver is a mid-range desktop computer from 2018 and I regularly code on a laptop from 2012, and even then it's completely manageable: cargo check is nigh instant on both, incremental compilation in debug mode is more than fast enough and even incremental rebuild in release mode and full debug builds are OK-ish (especially since they don't happen as often as the other above). There's only full builds in release mode that are arguably slow in the 2012 laptop (though on the project where it's the biggest problem, the majority of the time is spent compiling a C++ dependency), but then again it's a very obsolete piece of hardware and this isn't supposed to happen more than every six week when you update your compiler toolchain.
I welcome you to try to work on a cxx-qt project to understand what crippling compile times look like.
I’m not memeing here, I’ve struggled with this issue on a variety of different projects since I first started using Rust seven years ago.
Everything about cxx-qt is wrong. The Rust ecosystem deserves better. Not QML. Not any markup-like things like Slint. No immediate mode. And definitely not GTK. So much wasted potential.
So... what do you think GUI on rust should look like?
This really depends on what you are working on. As an example, compiling the protobuf stuff can get insanely slow for some reason.
For any larger project I would recommend working with a cargo workspace to compile as little as possible on each check/test/run/build.
Then you can build a DAG of crates and stick e.g. the Protobuf stuff in its own separate corner where it only needs to be recompiled on full rebuilds or when you work on it.
Feels a bit shitty to have to resort to managing crates instead of modules simply due to the compile times, but it is what it is.
https://doc.rust-lang.org/cargo/reference/workspaces.html
Yeah, second that. This is just release management best practice.
And it makes total sense to me, it’s a way of organizing your dependency graph by the lifetimes of your components.
This will also simplify testing, development, and audit. You won’t need to recompile autogen schemas as often as the business logic implementation anyway. Depending on artifacts pushed through a release pipeline is even more reliable. You can QA everything in guaranteed isolation while keeping it conveniently a workspace monorepo.
If only someone had a way of automating this! Say perhaps using some kind of digital computer...
I wish rustc could automatically build a DAG of “smallest group of modules with cyclic references” and use that as a compilation unit, but that's unfortunately not the case so far and it won't until someone steps up to build such a system.