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
Crates is widely used so it's a rebuilding the track while the train is driving kind of problem.
It's just not a priority for the project right now, but I would also definitely like to see the issue done. It might be good for the rust project to vote on things like this during surveys so they know where to focus work!
TL;DR: They want to fix this, it's a lot of work that no one's being paid to do, there's a roadmap with specific tasks that need doing, volunteer contributions are welcome.
> it's a lot of work that no one's being paid to do,
aren't they like some kind of non-profit (in the legal sense) that is still able to take a lot of money (from players like Google and Co, to justify fixing this), as opposed to ... say the Zig foundation, ... that is is also "non-profit" but can't get money the same way?
The non-profit (the Foundation) pays for specific things but it is not really there to hire people to work on things. It pays for infrastructure work and to pay the existing maintainers who often do review work. It also gives stipends to up-and-coming contributors for Open Source outreach programmes, but this are not really the people who you want to have immediately work on your critical infrastructure code.
10 years ago, GitHub had a far better reputation and the Rust ecosystem was much smaller and less load-bearing, so "what if someone doesn't have a GitHub account" was a theoretical concern for most people. So the issue was a low-priority backlog item that everyone agreed would be nice-to-have but there weren't enough people willing to volunteer their time to it over more important and more impactful work.
Obviously, the situation has changed in recent years, so it's now considered a much higher priority by many people and some of them are actively working on it. But it's a lot of work to be done by volunteers, so it takes time.
That's the reality of open-source projects: things get done when they are important enough to motivate someone to either fund it or work on in their free time, not according to idyllic roadmaps and schedules.
The reason people were sounding the alarm 10 years ago is because if you tie yourself to a proprietary platform then you're at its mercy, even if it changes for the worse for everyone which is what we're seeing now.
With open-source projects, realistically there is no shortage of alarm sounding, and there is a shortage of alarm fixing, consequently if you really care about this being fixed you have to volunteer to go fix it.
Open source projects tend to be (and Rust certainly is) a showupocracy. Shit gets done when people that care about that shit does it. This means that important stuff that everyone agrees is important but not important enough for me to do, doesn't get done. And that some things end up being 80% solutions that scratch the itch of the person driving a project and progress stalls beyond that.
With Github, both of those things are gated behind Microsoft accounts, which will be an absolute no to a lot of volunteers. Particularly the ones who would fix that problem.
From the outset, crates.io was careful to deliberately not tie itself inextricably to Github. For example, by resisting the endless deluge of people demanding that Github usernames be used as public-facing package namespaces. Github is only used as an identity provider for logging in.
> 10 years ago, GitHub had a far better reputation
While this might have been true in rust-circles (which I'm an outsider to), I think this varied a lot in different circles. Most free software projects invested a lot of money, time and effort in setting up better (for themselves) alternatives to Github.
Everything from videolan and GNU Savannah to XDG, Gnome, KDE, etc.
Go handles this well, kind of. It's super easy (in fact, transparent) to import from GitHub urls. You can self-host your Go packages, but it involves making and hosting some manifest files. Not as seamless as using GitHub, but still totally doable.
Aren't all the ones in the actual Go registry mirrored, though? I thought I read that. They also make it trivial to vendor dependencies, idk if Crates handles that
I think crates.io is essentially just the default, and you can point cargo to an alternate package repository, if you so desire.
I've worked on projects where we vendored all third-party crates, for example, so our config just pointed to that vendoring, and I think support ought to be better these days…
The longer I go the more I have actually come to appreciate the way Packagist works for the PHP community, there are lots of cool things it does that I wish NPM or other registries did by default, like forcing you to package from a source repository, so that you can't upload a different artifact from what you keep in source control.
I'm not sure that really gives you the guarantees you think it does, though.
For example, I could push some malicious code, tag it, wait for Packagist to finish pulling it to publish a package, and then amend history to remove the malicious code, rewrite the git-tag, and force-push both to the git server.
This scheme makes it hard/impossible to push mismatching code by accident, but doesn't do much to stop a malicious actor.
This kind of thing is one of the reasons crates.io distributes source only, and that published crate dependencies can't depend on other repositories (that might allow for that attack).
From a supply-chain perspective, Cargo is still in the same broad risk category as npm and PyPI: installing packages means trusting externally published code, including code that may execute during build or installation.
Rather than looking for someone to blame - in this case, GitHub - we should focus on constructive ways to harden the ecosystem.
That's a separate issue of supply-chain risk, and crates.io using GitHub auth isn't really material to that.
The gripe with using GitHub auth for crates.io is that GitHub is owned by a large, fickle corporation with a (shall we say) complicated history with open source, and people object on principled grounds to being forced to use GitHub in order to participate in the crates.io ecosystem.
GitHub, just like NPM, is a liability of the worst order. I'm sure it's just coincidence that both are owned by Microslop. Anyway, having either of those as a mandatory dependency is a big no-no.
Cargo tied itself to GitHub back when GitHub still looked like an open-source utopia. Now the dependency is deeply baked in, and rolling it back would be very hard.
The teams support may be a bit trickier/less clear to move on, but generally: this feels like a great place where atproto / bluesky support would slot in well.
The only thing GitHub is used as on crates.io is as an identity provider. Using your atproto identity is pretty straightforwardly a conceptual substitute.
Not sure what your mean, Golang has solved this problem. Packages are not dependent on GitHub, and trust and namespacing is done by domain which works really well.
In my personal opinion, if a rogue actor can compromise your project by buying you the equivalent of a beer and a pizza, I don't think anyone should trust you as a dependency to any extent.
Average monthly salary in Nigeria is $220.42. Median monthly income is $65.02. Minimum wage is $0.26/hour.
I know this kind of money sounds banal for us now, but even I, when I was a student (especially in high school), tried to avoid spending any money on my hobby (programming).
Using crates.io is entirely optional, you can download a library's source code and specify the path to it in your cargo config file. (Which is not uncommon in production)
For that matter, using cargo is optional, you can compile rust code using GNU make or shell scripts if you want to. (That's what the Linux kernel does)
An RFC was recently merged to unblock this: https://github.com/rust-lang/rfcs/pull/3963
The implementation on this has started.
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.
> much more work on the package manager side to make sure that orgs are actually related to the company
In a world without namespaces, how does anyone know google-foo belongs to Google?
At least if you establish "@google" belongs to Google, then you can be fairly confident "@google/foo" is theirs.
> (what if someone had created an Anthropic user name back in 2016?)
https://github.com/anthropic
https://github.com/anthropics
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).
https://internals.rust-lang.org/t/survey-of-organizational-o... is a start in just collecting existing knowledge in one place.
> 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)
> https://github.com/rust-lang/rfcs/pull/3963
Ironically hosted on GitHub.
Except it is a company: https://rustfoundation.org/
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
The Rust Foundation has explicitly no bearing on what the Rust Project does. They are not as related as one would think given the names.
Feel free to point at 1 thing that the rust-lang didn't do because the Foundation blocked it.
I agree and so does the rust project. The main problem is that it's alot of work and it's hard.
https://www.youtube.com/watch?v=zGS-HqcAvA4 Here's a long video from jon gjengset that shows how it works and some of the effort already done to de-couple from github.
Crates is widely used so it's a rebuilding the track while the train is driving kind of problem.
It's just not a priority for the project right now, but I would also definitely like to see the issue done. It might be good for the rust project to vote on things like this during surveys so they know where to focus work!
See the official project issue on this: https://github.com/rust-lang/crates.io/issues/326
TL;DR: They want to fix this, it's a lot of work that no one's being paid to do, there's a roadmap with specific tasks that need doing, volunteer contributions are welcome.
> it's a lot of work that no one's being paid to do,
aren't they like some kind of non-profit (in the legal sense) that is still able to take a lot of money (from players like Google and Co, to justify fixing this), as opposed to ... say the Zig foundation, ... that is is also "non-profit" but can't get money the same way?
The non-profit (the Foundation) pays for specific things but it is not really there to hire people to work on things. It pays for infrastructure work and to pay the existing maintainers who often do review work. It also gives stipends to up-and-coming contributors for Open Source outreach programmes, but this are not really the people who you want to have immediately work on your critical infrastructure code.
That reminds me tailscale still depends on anyone-but-them for identity...
Just going to say it out loud :) Its been known for 10 years.
https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...
10 years ago, GitHub had a far better reputation and the Rust ecosystem was much smaller and less load-bearing, so "what if someone doesn't have a GitHub account" was a theoretical concern for most people. So the issue was a low-priority backlog item that everyone agreed would be nice-to-have but there weren't enough people willing to volunteer their time to it over more important and more impactful work.
Obviously, the situation has changed in recent years, so it's now considered a much higher priority by many people and some of them are actively working on it. But it's a lot of work to be done by volunteers, so it takes time.
That's the reality of open-source projects: things get done when they are important enough to motivate someone to either fund it or work on in their free time, not according to idyllic roadmaps and schedules.
The reason people were sounding the alarm 10 years ago is because if you tie yourself to a proprietary platform then you're at its mercy, even if it changes for the worse for everyone which is what we're seeing now.
With open-source projects, realistically there is no shortage of alarm sounding, and there is a shortage of alarm fixing, consequently if you really care about this being fixed you have to volunteer to go fix it.
Open source projects tend to be (and Rust certainly is) a showupocracy. Shit gets done when people that care about that shit does it. This means that important stuff that everyone agrees is important but not important enough for me to do, doesn't get done. And that some things end up being 80% solutions that scratch the itch of the person driving a project and progress stalls beyond that.
With Github, both of those things are gated behind Microsoft accounts, which will be an absolute no to a lot of volunteers. Particularly the ones who would fix that problem.
The comment you are replying to was in response to essentially the same point, albeit with fewer words and less emphasis.
From the outset, crates.io was careful to deliberately not tie itself inextricably to Github. For example, by resisting the endless deluge of people demanding that Github usernames be used as public-facing package namespaces. Github is only used as an identity provider for logging in.
Wow, have you forgotten? https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
10 (edit: 8) years ago MS took over Github. The writing was on the wall then...
No need to explain OSS to me, I maintain and contribute.
crates.io was started long before the GitHub acquisition.
Yes, and your point?
> 10 years ago, GitHub had a far better reputation
While this might have been true in rust-circles (which I'm an outsider to), I think this varied a lot in different circles. Most free software projects invested a lot of money, time and effort in setting up better (for themselves) alternatives to Github.
Everything from videolan and GNU Savannah to XDG, Gnome, KDE, etc.
Pro tip: Using "load-bearing" is heavily associated with LLM usage :)
It's pretty sad that people are suggesting we not use perfectly-good English idioms anymore just because LLMs seem to like them.
The reason LLMs seem to like them is because humans liked them first.
You could say it’s the real smoking gun. With significant blast radius.
Pangram says human: https://www.pangram.com/history/208879e5-8510-479a-b96c-a20f...
This is where I would insert the Little Britain "Computer says no" meme.
It is also heavily associated with humans writing about things which bear load (in an xkcd #2347 sense) :)
Counterargument: https://www.astralcodexten.com/p/come-on-obviously-the-purpo...
A really popular saying on HN that's completely nonsensical under even a small amount of scrutiny.
Go handles this well, kind of. It's super easy (in fact, transparent) to import from GitHub urls. You can self-host your Go packages, but it involves making and hosting some manifest files. Not as seamless as using GitHub, but still totally doable.
In practice, Go is much, much more github dependent than rust, most go packages are on github
Aren't all the ones in the actual Go registry mirrored, though? I thought I read that. They also make it trivial to vendor dependencies, idk if Crates handles that
Crates.io hosts source code independently of GitHub.
Cargo also makes vendoring dependencies trivial.
My take: publishing Rust crates shouldn't depend on any single internet property, including crates.io.
I think crates.io is essentially just the default, and you can point cargo to an alternate package repository, if you so desire.
I've worked on projects where we vendored all third-party crates, for example, so our config just pointed to that vendoring, and I think support ought to be better these days…
Correct. You're welcome to mirror or host a private one. Cargo makes it _relatively_ easy to do (saying this as somewhat of a cargo hater).
I mean... it technically doesn't? You can always point to other registries (or you can even just pull in git repos), we literally do this at work.
The longer I go the more I have actually come to appreciate the way Packagist works for the PHP community, there are lots of cool things it does that I wish NPM or other registries did by default, like forcing you to package from a source repository, so that you can't upload a different artifact from what you keep in source control.
I'm not sure that really gives you the guarantees you think it does, though.
For example, I could push some malicious code, tag it, wait for Packagist to finish pulling it to publish a package, and then amend history to remove the malicious code, rewrite the git-tag, and force-push both to the git server.
This scheme makes it hard/impossible to push mismatching code by accident, but doesn't do much to stop a malicious actor.
This kind of thing is one of the reasons crates.io distributes source only, and that published crate dependencies can't depend on other repositories (that might allow for that attack).
How does a close source package work? Depending on the language its not super helpful, but a package that is closed source should be possible.
For crates.io: They don't allow closed-source packages. But they're just the free community package index, you're not forced to use them.
You can:
- host a private index
- host the proprietary binaries in a git repo and use a git dependency
- commit the proprietary binaries into your source repo, and use a path dependency
crates.io also only distributes source code.
From a supply-chain perspective, Cargo is still in the same broad risk category as npm and PyPI: installing packages means trusting externally published code, including code that may execute during build or installation.
Rather than looking for someone to blame - in this case, GitHub - we should focus on constructive ways to harden the ecosystem.
That's a separate issue of supply-chain risk, and crates.io using GitHub auth isn't really material to that.
The gripe with using GitHub auth for crates.io is that GitHub is owned by a large, fickle corporation with a (shall we say) complicated history with open source, and people object on principled grounds to being forced to use GitHub in order to participate in the crates.io ecosystem.
I'm working on a tool for collaboratively reviewing Rust crate dependencies: https://github.com/thirdpass-org/thirdpass
Also supports npm, PyPI, and Ansible Galaxy.
GitHub, just like NPM, is a liability of the worst order. I'm sure it's just coincidence that both are owned by Microslop. Anyway, having either of those as a mandatory dependency is a big no-no.
Cargo tied itself to GitHub back when GitHub still looked like an open-source utopia. Now the dependency is deeply baked in, and rolling it back would be very hard.
The teams support may be a bit trickier/less clear to move on, but generally: this feels like a great place where atproto / bluesky support would slot in well.
I don’t see how that would be effectively useful for any aspect of the problems
The only thing GitHub is used as on crates.io is as an identity provider. Using your atproto identity is pretty straightforwardly a conceptual substitute.
Sadly, that's probably correct. No outside single point of failure that can cancel users at will can be allowed to gatekeep open source projects.
Especially not now, what if they're down? ;)
This is a big issue. https://janetdocs.org/ handles auth through GH which leads to... regular problems, unfortunately. I hope to migrate soon.
Welcome to Golang packaging problems. Hope you get it sorted out
But Sylvain Kerkour says Go's approach is much better than Rust's!
Not sure what your mean, Golang has solved this problem. Packages are not dependent on GitHub, and trust and namespacing is done by domain which works really well.
Can someone explain to me why the inverse domain name solution that everyone in the Java world converged on doesn't work?
It's really not clear to me why people keep avoiding that.
1) Trawl registry for packages owned by domains.
2) Note expired domains and register them yourself.
3) Supply chain compromise.
That, and not wanting people to fork out money for a domain as a requirement to participate in the ecosystem.
In my personal opinion, if a rogue actor can compromise your project by buying you the equivalent of a beer and a pizza, I don't think anyone should trust you as a dependency to any extent.
$10/year is too high a price when I spend that much on my morning Starbucks order…
Average monthly salary in Nigeria is $220.42. Median monthly income is $65.02. Minimum wage is $0.26/hour.
I know this kind of money sounds banal for us now, but even I, when I was a student (especially in high school), tried to avoid spending any money on my hobby (programming).
The shape is very different. The only thing crates.io uses GitHub for is for identity.
[flagged]
Using crates.io is entirely optional, you can download a library's source code and specify the path to it in your cargo config file. (Which is not uncommon in production)
For that matter, using cargo is optional, you can compile rust code using GNU make or shell scripts if you want to. (That's what the Linux kernel does)
Still many more reasons to learn C!
I chose to learn C 25 years ago and avoid it now whenever I can. Life's too short to deal with memory unsafety.
Welcome to 1972, young padawan. You have a long journey ahead of you.
There’s been advancement since then old timer.
Peak programming.
Holy fuck it’s been a decade. Nothing is that complex.
PRs are welcome.
You do it then, if it's not rocket science :) or donate to the project, clearly you have a lot of it to spend by making demands of peoples' free time.