> 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).

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.

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.

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.

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

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

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.

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.

Still many more reasons to learn C!

Peak programming.

There’s been advancement since then old timer.