A Vision for Cargo
According to Stack Overflow, cargo is the most desired development tool.<br>Many people attribute their choice of Rust to Cargo.<br>I've heard from many people that Cargo is already great and that they can't think of any way it could be improved.<br>I want to set our sights higher.
And I want to hear your thoughts on what an ideal workflow would look like and how we might get there.<br>This is just some things I've been thinking about.<br>I know I don't know or can't easily speak to all of the workflows<br>and others might have even better ideas on how to solve them.
We can also use your help in getting there.<br>These workflows are not isolated to just Cargo but also touch on Rust, crates.io, and more.<br>There are plenty of opprtunities to dig in and help.
Some workflows to improve
I want to frame this discussion around a high level view of workflows.<br>I'll cover specific problem areas (e.g. build scripts) as part of the ideas on how to improve them.
#[non_exhaustive]
Dependency management
Build performance
Adaptability
Cargo maintenance
Also, a word on agentic development
Dependency management
“Always bet on the ecosystem”
- Battery packs: Let's talk about crates, baby
I feel strongly that the crates.io ecosystem has been one of Rust's superpowers,<br>enabling applications to be rapidly created with more capabilities and polish than would be practical without this ecosystem.
Applications can leverage not just the existing functionality but any future functionality and fixes.<br>For example, ripgrep is being optimized for large monorepos and typos automatically benefits due to reusing ignore.<br>A fresh implementation or a fork would not see benefits like this.<br>This also enables shared auditing.<br>In your application,<br>you can have one or two serialization frameworks also in use by others<br>or you can audit ten bespoke ones spread across config systems, network communication, etc.
Dependencies are not without their costs and risks which we should work to drive down.
How do you discover a quality dependency?
There are "known" dependencies to use,<br>assuming you are in the know.<br>Being productive shouldn't be gated on insider knowledge.
When there isn't a "known" dependency,<br>you are then left to find candidates which isn't always easy.<br>To compare them, you then look for a smattering of signals to see if it is safe, fit for your purposes, and can be depended on for the long term.<br>These may include download count, who depends on it, reviews performed, etc as well as trust carried over from other packages from the author.<br>Knowing and aggregating these can take a lot of work.
In the ideal world,<br>all dependencies would be reviewed.<br>We aren't in an ideal world but how do we get closer?<br>In Rust, we have unsafe as a way to isolate code that needs further inspection.<br>We need more types of audit points and to scale up their discoverability.<br>Even better if you didn't need to review these audit points<br>because they were opt-in where possible,<br>with a fallback that didn't need audits at the cost of performance or features.<br>Sometimes though,<br>we will still want to take shortcuts and trust in others for reviews<br>and tracking of our own or others' reviews should be integrated with using dependencies.
How do we minimize upgrade overhead?
First, we need to improve the state of linting and testing for maintainers so there are fewer bugs and unintended changes.
Assuming we are now talking about intended changes,<br>the easy answer would be to discourage breaking changes<br>but that comes at a cost to the maintainer in not being able to clear out some types of technical debt<br>and to users in the limits this places on features, fixes, and build performance.
We should encourage documenting changes and better surface that.<br>However, that is a stopgap that patches over the problem.<br>How can we make this better?
One source of inspiration is the Rust Language<br>which also has a form of opt-in breaking changes through Editions.<br>The Rust Project prepares for an edition with unstable features and by providing migrations for users.<br>That should be viewed as the minimum experience we offer maintainers and users for packages.<br>Going beyond that, we could better surface these changes to users,<br>inline to their workflows and directed to their specific circumstances.<br>This would especially be important for when migrations aren't possible.
As an experiment in what can be done today,<br>with clap I have adopted the practice of breaking changes being introduced as parallel features, deprecating the old behavior with a note in how to migrate, where possible.<br>The deprecations have been put behind a deprecated feature flag because many people turn warnings into errors, including deprecations, and having them on by default coupled upgrading with resolving deprecations increasing costs and risks.<br>This dramatically simplifies migration guides to "enable a feature and do what it says".<br>Where a parallel feature isn't possible, we use an unstable-vX feature to not block...