--- title: "A Vision for Cargo" url: https://daily.dev/posts/a-vision-for-cargo-9f2kssnoj source_url: https://epage.github.io/blog/2026/08/cargo-vision type: article source: "Lobsters" published: 2026-08-06T07:24:31.762Z updated: 2026-08-06T20:07:31.098Z tags: ["security", "rust"] reading_time: 32 upvotes: 1 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # A Vision for Cargo **[Lobsters](https://daily.dev/sources/lobsters)** · 32 min read · 1 upvotes · 0 comments ## Summary A comprehensive vision for improving Cargo, Rust's build tool and package manager. Covers four major workflow areas: dependency management (discovery, auditing, upgrade overhead), build performance (incremental builds, caching, unnecessary rebuilds), adaptability (plumbing commands, programmatic output), and Cargo maintenance (architecture modernization). Specific proposals include async-ifying Cargo, migrating from libgit2, adopting PubGrub for dependency resolution, adding structured logging, open namespaces, public dependencies, proc-macro/build script access controls, crate provenance tracking, shared build caches, opaque dependencies, and test result caching. Also discusses how these improvements benefit agentic development workflows. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 3 discussions and 17 comments across lobsters, hackernews (as of 2026-08-06). **TL;DR:** Commenters broadly appreciate Cargo's value, especially compared to C/C++ and Java build tooling, though CI caching limitations and the opaque target directory are called out as real pain points driving some teams toward Bazel. **Sentiment:** 55% positive · 30% mixed · 15% skeptical **The case for** - Having a single, blessed build tool eliminates the fragmentation seen in Java, Python, C++, and other ecosystems. - Cargo's assumption of semver, ability to depend on multiple crate versions simultaneously, and automatic locking make it nearly friction-free for both consumers and producers. - The standardization around Cargo means interoperability across the ecosystem is high, reducing snowflake project setups. - Cross-platform builds, test runs, and debug/release switching all work with a single command out of the box. **The pushback** - CI caching is a major weakness: the target directory is enormous and opaque, hosted CI providers can't do incremental updates, and trivial changes can invalidate the entire cache. - sccache can't work optimally because it lacks true dependency information from Rust/Cargo and must reconstruct it heuristically. - Some large projects are migrating to Bazel specifically for its caching capabilities, despite Bazel's own complexity. - Build scripts feel like writing a fragile manual build system in Rust rather than a principled abstraction. - There is no clean way to treat an entire workspace as a single logical dependency unit rather than enumerating each member crate separately. **By community** - lobsters (mixed): Mostly positive on Cargo's ecosystem value and cross-platform ergonomics, but with a notable thread about CI caching pain pushing teams to Bazel, and one commenter who remains unconvinced Cargo is exceptional at all. - hackernews (mixed): No comments were available to assess sentiment. **Hottest debate:** Whether Cargo's CI caching limitations are severe enough to justify migrating large projects to Bazel despite its added complexity. **Open questions** - Will the proposed shared build cache and opaque dependencies actually solve the CI caching problem without requiring Bazel? - Should artifact dependencies be a prerequisite before Cargo can realistically replace Bazel for large monorepo use cases? - Is there a principled way to expose workspace-level dependency grouping in Cargo.lock and cargo tree? **Highlights** > To me lack of good CI caching support is the biggest drawback of Cargo. The `target` dir is enormous and opaque to users. Hosted CI providers don't integrate with it (other than by giving an option to download and re-upload the whole thing as a tarball, no incremental update). `sccache` doesn't work as well as it could, because it has to be very conservative due to lack of true dependency information from Rust/Cargo (it tries to reconstruct it from rustc args and cargo env vars, but that's not quite correct in edge cases). And it's soooo easy to invalidate the whole build cache due to a triviality. For ages Mac Docker had a bug that truncated nanoseconds from some filesystem timestamps, making crates with `build.rs` uncacheable 50% of the time. The pain is so big, that at my `$WORK` big projects are switching from Cargo to Bazel. I don't find Bazel pleasant to work with, especially the weirdness of reimplementing entire `cargo` as a Bazel plugin, but it can do caching. > — [kornel on lobsters · 9 points, 3 comments](https://lobste.rs/s/mgr9lc/vision_for_cargo#c_mrggjy) > When I say 'Rust is the greatest', it's hyperbole, but when I say 'Cargo is the greatest', it isn't. I have used a lot of different dependency systems and Cargo, or rather the Cargo experience, which includes Rust features like `cfg` and other tools like `rustdoc`, seems obviously superior to all of them. Assumption of semver, being able to depend on more than one version of a crate at a time, principled separation of dependency node info from local build profile info, supreme empowerment of build scripts, automatic locking and installation, and many other things besides, all come together to make `cargo build` not only Just Work but be almost friction-free ~100% of the time as both a consumer and a producer. I spend so much time in Rust world that it's always a culture shock when I return to some other environment temporarily. You forget that, in Gradle, all your dependencies must be using the same version of a library, and that working around this requires both a plugin and a new task graph endpoint. > — [pie\_flavor on lobsters · 1 points, 1 comments](https://lobste.rs/s/mgr9lc/vision_for_cargo#c_nkllua) > The important thing is that everyone in the Rust ecosystem agreed to use Cargo. The value of interoperability and elimination of snowflake projects is greater than Cargo's actual feature set. > — [kornel on lobsters · 2 points](https://lobste.rs/s/mgr9lc/vision_for_cargo#c_r0bdfl) > How much experience have you had catering to C/C++, possibly java or JS, build systems and pipelines? And keeping them running over years? If you had, especially the C/C++, you would understand. You can run test and it just works in one command. You can compile in one command and it just works. You can cross compile and it just works. You can change produce a debug build or a prod build in a command without touching anything and it Just Works!!!!! Also you can run the same command on Mac and on Windows and on Linux and **It Also Just Works**!!!!!!!! WTF Is this black magic!!!!1 None of that is normal in these environment. Getting anything with a dependency to compile is usually a multi hour journey, and not a nice one. One in which you lose sanity and bash your head against the desk multiple time, if you can even get it to work. Cargo is the best thing that happened to system level people since... probably since the 80s. > — [Diana on lobsters · 1 points, 1 comments](https://lobste.rs/s/mgr9lc/vision_for_cargo#c_zenpix) **Source threads** - [lobsters](https://lobste.rs/s/mgr9lc/vision_for_cargo) · 32 points · 17 comments - [hackernews](https://news.ycombinator.com/item?id=49193405) · 1 points · 0 comments - [hackernews](https://news.ycombinator.com/item?id=49189434) · 1 points · 0 comments ## Similar posts on daily.dev - [This Development-cycle in Cargo: 1.94](https://daily.dev/posts/this-development-cycle-in-cargo-1-94-pibq8md8q) · Inside Rust Blog · 21 upvotes · 2 comments - [This Development-cycle in Cargo: 1.90](https://daily.dev/posts/this-development-cycle-in-cargo-1-90-086u2xvnh) · Inside Rust Blog · 3 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security), [#rust](https://daily.dev/tags/rust) [View this post on daily.dev](https://daily.dev/posts/a-vision-for-cargo-9f2kssnoj)