Because that would also cause the dependencies to be compiled in series also! The point was only to measure "what if the Bun crate was built in one shot" not any dependencies of Bun.
Yeah, I'm not really sure how to feel about the way they plan to handle it.
"Happy it exists at all" resonates. Most accessibility users find something inaccessible, sigh, and move on. Most of the time there is nothing we can do, and most of the time the complaint platform itself is inaccessible. We're taught not to complain.
But... The idea of a NO_GRAPHICS env var? I don't particularly like that. Its a hidden, unstandardised, global. To discover it exists, I have to first use the software in its inaccessible form - where I'd find it inaccessible, sigh, and move onto something else.
Again, the problem is discovery - if this is an optout, and the system that tells you is the same thing that you need to change to be able to use it in the first place, the audience just feels the usual crush and moves on.
We are trading away disk space for faster builds. We could make them faster in some cases by using even more...
On the other hand, it would be good to garbage collect those caches. We are wrapping up work on a new layout for intermediate build artifacts that will make it easier to GC them.
Sounds like what I was thinking, that or for third party deps to go into the same temp folder, and anything not accessed in over a week, or so just gets auto wiped by rustc / cargo build process?
Something to keep in mind is https://blog.m-ou.se/rust-is-not-a-company/. Rust is mostly driven by volunteers working on what they find interesting. Boring/uninteresting tasks depend on funding, a warm body to accept the funding, and a reviewer.
It's not just that this is boring work, but there's disagreement about Cargo and crates.io's direction. There are a lot of changes people would like to make that get turned down.
Crates.io and Cargo need namespaces, but the leadership flatly says no.
There's a big problem with name squatting, and nothing is being done about this either.
I get that there are more technically important issues around builds and reproducibility and the like, but this is pretty foundational stuff.
> Crates.io and Cargo need namespaces, but the leadership flatly says no.
They are favorable to crate-name-as-namespace (so that once you have the tokio crate you can use tokio as a namespace) and there's ongoing work on that. But as said above, it takes work to implement.
There's no desire for other meaning of the word "namespace" because famously nobody ever made a well-reasoned proposal (despite the amount of social media outrage over the lack of namespace).
There's just so much prior art here, though. Docker hub has username-based and org-based namespaces (as well as a "blessed package" root with no namespace). Maven central uses reverse-DNS as a namespace (and Maven central/OSSRH requires that you prove you own the domain before you can publish to it). Even npm, probably the poster child for doing things wrong, has user- and org-based namespaces.
This isn't a particularly difficult problem, and other package ecosystems have solved it many times in the past.
Arbitrary user-based or org-based namespace have many drawbacks: to name a few it makes discoverability much worse, and as such makes it easier to sneak in a malicious dependency, and it requires much more work on the package manager side to make sure that orgs are actually related to the company they use the name from (i.e. how do you make sure that the org "Google" in your package manager does indeed belong to GOOG), and a litigation process to resolve conflict (what if someone had created an Anthropic user name back in 2016?).
And on the flip side nobody has ever been able to articulate (that is, not in a hand-wavy fashion) what do those actually bring on the table to make those extra costs worth it.
Lol. The world seems to be moving along just fine.
I don't think the problems you list are problems at all.
Meanwhile, the benefits of knowing everything under a user/org namespace belongs to a user/org are huge.
There are much bigger problems to worry about than this. Such as if a popular crate owner sells out to malware for $$$.
It's also much easier to control ownership and auditing of @tokio/xyz than it is tokio-xyz. The org can uniformly control permissions to all member crates without having one go rogue.
> In a world without namespaces, how does anyone know google-foo belongs to Google?
It doesnt. And nobody believes it does. That's the key difference.
> At least if you establish "@google" belongs to Google, then you can be fairly confident "@google/foo" is theirs.
In practice nobody “establishes” that, they just trust the platform for vetting the orgs (and they are right, because they usually do), so if you package manager uses the same formalism without the same guarantees, you're setting yourself for a bad time.
> Lol. The world seems to be moving along just fine.
You've just shown an example that it doesn't! If you have two packages "anthropic/claude-code" and "anthropics/claude-code" how is the user supposed to know that the scammy-looking second option is the legitimate one?
> There are much bigger problems to worry about than this.
The thing is that mandatory namespaces don't provide meaningful benefit at all.
> It's also much easier to control ownership and auditing of @tokio/xyz than it is tokio-xyz.
This is covered by the accepted “crate as namespace” proposal. It has the benefit of keeping a flat namespace by default and providing an optional namespace for open source projects like that.
That and the existing reply are incorrect. Almost everyone has repeated the same superficial requests and design work and not dug into the problems to come up with a proposal that respectfully threads seemingly contradictory requirements (the answer isn't to be dismissive but to step through costs/benefits and explain why a path is justified).
> There's a big problem with name squatting, and nothing is being done about this either.
That's not true at all. They changed the policy a few years ago to disallow squatting and you can report a package as not doing anything, at which point they'll send the author an email with a deadline to respond, with the plan to remove the crate if there's no change. I actually had this happen firsthand from a package name I had claimed in the early days, forgotten about, and then gotten this email about several months back:
> Jan 29, 2026, 19:25 UTC
> Hi saghm, I'm a member of the crates.io support team, and I'm writing in regards to your pal crate.
> Our policies have changed, and we now disallow crates that have no functionality. The pal crate was reported to us as violating this policy.
> Are you still using this crate name? If so, please reply-all and let us know by February 12, 2026. If we don't hear back from you by that date, we will be removing this crate.
> The rest of your crates are fine and will NOT be removed.
(I responded back immediately to confirm I wasn't using the crate and hadn't been aware of the policy change, so they could take action immediately without needing to wait until the deadline)
And you forgot to mention the bureaucratic process that also blocks warm bodies from developing code because the changes are not/unlikely to be accepted regardless of the level of excitement
As a prolific PR author, I've found how I communicate has a major factor on how well and quickly people respond to PRs. I've recorded my lessons at https://epage.github.io/dev/pr-style/.
As a reviewer, I love type first because it sets expectations for what I'm going to look at. Similar if I'm bisecting or doing other history operations.
I don't do automated changelogs or versioning but it also makes it faster for me to do so.
I really dislike focusing on issue ids. I only want to jump to another tool if I need more information, so put it in the footer for after I've read what is there, like a front page news article giving you the option to go to the back to read more. Worst case that I've seen is people that think the Issue ID is all you need.
Not having used uv but being on the Cargo team for Rust, I wish `cargo update` was `cargo lock update` because it is making our life more difficult to add a version requirement update command/mode inside of Cargo. The effort has been stalled for years.
- Our compatibility guarantees mean we can't fundamentally change `cargo update`
- Using the third-party package name of `cargo upgrade` would be confusing in the distinction between the two
- We have to be very careful adding the mode to the existing command
An important part to me that gets overlooked is shared logins. Rust runs the tests of all known Rust projects in a tool called `crater`. I was analyzing a run identifying projects relying on internals of Cargo and opening issues. When making 200 issues by hand, it is a big help when the process is low friction: I had credentials for the site and allowing blank templates. Any time I came across a self-hosted instance, I usually ended up giving up.
This is something federation could help with: you would be able to use your account on, say, Codeberg to make issues on all self-hosted instances. Sadly, it’s still not in a great shape: https://forgefed.org/
(As a fallback, why not email the maintainers instead?)
I appreciate you recognize there is still a reason for grouping commits into mergeable units (PRs). Some go too far and only want every commit to be independent.
I also appreciate the ordering. In my projects, we put an extra focus on tests by having having a commit that adds new tests to reproduce the bad behavior so when you diff the tests with the fix commit, you get a visual of how things changed.
I also find that the order can be PR specific. I wonder about allowing the contributor or reviewrs reorder on per-PR basis.
There are also times we have a lot of test or doc changes. I wonder about grouping items to jump between or collapsing to more easily navigate around than opening and browsing a file picker.
Yeah, having `cargo test` require another binary like `uv` is not idiomatic. 99% of the time, I should be able to walk up to a Rust project and run `cargo test` and it should just work.
Still won't be quite apples to apples because a multi-crate project will serialize more to disk.
reply