Cargo doesn't recompile all crates on each iteration, you are missing something definitely. It only recompiles changed code. Or if rustc/cargo version has been changed.

"a bit of catch up" is one thing, not mentioning most powerful IDE plugin is another.

This is not what I see, I imagine you are talking inside one single project, while I mean across all Rust applications I might have available.

1 - Get Project A

2 - Crate X gets compiled as one of the dependencies

3 - Get Project B

4 - Crate X gets compiled again as one of the dependencies

I usually see this when compiling all the VSCode related projects during new Rust releases.

Could the reason be that Crate X on Project A and Project B isn't the same version?

Where are the binary rlib visible to all cargo projects stored? I could only find text versions zipped together.

I haven't checked this deeply yet, just seeing "Compiling crate X" multiple times isn't fun.

We don't do any of this kind of caching because flags can be different per-project. There's an open bug on it; it's not impossible, we just haven't used it yet.

Same applies to any language that compiles to native code or has support for conditional compilation.

Even with MIR, Rust will never compile faster than C or even C++ if dependencies on binary libraries aren't supported.

Right now I can compile my C++ projects on Windows, and .NET Native ones, faster than when updating Rustfmt, racer and Rustsym, after each new Rust release.

VS2017 will bring the new linker, and the ongoing MS work for C++ modules (now a TS).

Rust won't win the hearts of C++ developers if it doesn't allow for binary dependencies, and doesn't compile faster.

All projects are independent and binaries are stored in "target" folder. It's a good thing. Even libs nominally same versions can have different source code and dependencies (because of "replace" or vendoring).

No, it is not a good thing. It is a waste of my development time that I could use for productive work.

On other AOT compiled languages that I use at work, I can reuse binaries across projects, including the languages Rust intends to replace.

It is a hard sell, if using Rust means having to spend more time compiling than even with C++ (specially now that modules are finally coming, at least for us with VC++).

For me is a good thing, because, as I explained, version number is not a guarantee.

So, than cargo needs to be improved so that there is a set of dependency values (name, version, rustc version, etc) that can guarantee the uniqueness of a binary library.

To me it seems FOSS undervalues the value of binary libraries in the enterprise, or how they get used in many corporations or companies selling components.

Rust improved safety is a good thing™, but not at the expense of continuously seeing the same libraries being compiled over and over, vs reusing binary artifacts across projects.

Cargo needs to be improved, here I agree :)

dub (D build tool) support both of these locations. I can attest stuff gets reused.

It doesn't have to use the version, it could hash the source, like ccache.

Needs better build support, CI testing and better tooling to match C++ on mobile.