It feels like this is worse than a package manager? As in why would I trust a random git repo to keep things up to date over the officially published channel?

I appreciate prople's efforts but they are misplaced. If I were passionate about this-- i'd do two things

1) A crates.io alternative which allows namespaces in package names like GitHub or alternatively. Single universal namespace doesn't seem fine (I don't think there would be necessarily changes required on the cargo side if users are willing to use full urls)

2) some kind of trust system so a user can up/down vote a package

3) Take a small one time payment for verifying a package? I don't know how this would work.

But I always thought NPM was what the author describes - just a random set of packages with git sources, which I thought was the main issue (leftpad etc.). Isn't that the case?

What about one system that just works and is there for "ages": maven repository?

Oh is that true? They tied themselves to Microsoft it seems. What about people who won't or can't use GitHub.

It's quite an, ahem, interesting mix of libraries, including three csv libraries, hyper_utils (but not hyper itself), and a ton of copied crates from other maintainers.

I hope the author has a good way of updating these with upstream fixes (some look out-of-date already), otherwise you may replace one security issue with another.

And the name stdx has been taken on crates.io, more than 11 years ago which can also be equally confusing.

1. What problem does stdx actually solve?

2. Ok, it's a git dep, seems fine? Why is the choice to publish or not publish in crates.io a big deal either way?

Also Debian tries to build and distribute independently from crates.io.

So crates.io is important but is not the (Rust) world.

And in general, people pointing at Rust "limited" stdlib (it's only limited compared to Python) as one of the big issue and risk with rust are, in my opinion, misguided. You will never make an stdlib big enough to remove the need for external dependencies. It also creates a bunch of other problems. Actually, to take Python as an example, some functionality being in the stdlib have created a bunch of issue over the years since you can't just introduce breaking changes in an stdlib as easily. Look at urllib2/3 or xml in python. In the end, almost everyone ends up using requests and lxml instead. There are many issues that need to be dealt with to mitigate supply chain attacks. A bigger stdlib or an "stdlib-extended" a la Boost, is not one of them.

Also, specifically for Rust, many people run in a no-std environment (anything sized constraint for the most part). So another stdlib would do nothing for them.