Why stdx is not on crates.io

Ok, I was curious enough to read look into this, but it makes no sense under the hood. The idea is essentially that:

1. Supply-chain problems affect the Rust ecosystem arguably even worse than npm. 2. `stdx` extends Rust by adding some other stuff in Go that's good for supply-chain security? 3. crates.io does stuff differently than stdx so that's why it's distributed exclusively via git.

But none of the README or article linked by the author or the other article linked in the README explain anything about what the good things from Go are that are actually added, or what the pain point precisely is compared to using crates.io. I think the first proposition is possibly correct, mainly because I know next to nothing about Rust but am all too familiar with supply-chain complaints (as are most of us by now) whether as to npm or Python ecosystems, and there is no principled reason why Rust should be more secure unless the fundamental assumption of trusting external packages to auto-update safely is somehow different in Rust. I assume without loss of generality that perhaps the author is right that Rust's package management ecosystem is no more secure as a supply-chain than Node.js's ecosystem. The second property also might be true too that Go offers some concrete solutions to the problem, though I have no idea if that's correct and wouldn't necessarily assume that to be true.

Still, even assuming all claims to be true, I do not see is any connection between those claims and actual implementation of code, aside from talk about how stdx is AI-friendly and was generated using AI. I just don't get what this does that is any different. You're still trusting a Git repository to be valid. In fact it almost sounds at one point like the author is suggesting that the whole exercise of providing proof of provenance and demonstrating that a particular version was properly published by its author is too tedious and annoying and should therefore be skipped by utilizing a simpler stdx approach to Rust (but I still don't know what that is or why I should trust it!). Is it just me? This makes no sense.

The whole "There are test vectors so we know it's correct" is a strong sign that this isn't actually safe to use and that indeed the people who built it (to the extent people actually did build it) have no idea what they're doing.

Sounds to me stdx is doing this wrong more than anything else.

> and instead tries to provide comprehensive support for low-level operations that enable you to build a custom-tailored solution to whatever you need on top of it

So in other words Rust forces you to either (a) re-invent the wheel (yet again !) or (b) import yet-another-crate into your project.

Of course if you choose (b), then its having first wasted your time deciding which of hundreds of yet-another-crate-doing-the-same-thing you want to import.

Its a waste of time and effort for the majority of projects where you are not working with embedded systems or trying to squeeze every micro-second of performance out of your system.

Sadly the majority of Rust projects show exactly zero import discipline, both from a pure import perspective and a security perspective. Which is why many Rust projects end up importing a gazillion crates.

Import discipline in Rust is hard work. Sure you can reach "reasonably necessary" level of imports the majority of Rust projects simply don't bother because its such a pain in the backside.

Don't get me wrong, Rust has its place in this world. But for many people on many projects they would be better off using Go and only using Rust where there is actually a serious use-case for it in their environment.

This is mostly only true if you're writing a network service or maybe a CLI tool. Which is fair enough, since that's what Go is primarily for, but Rust aims to be, not just usable, but the best option, in a broader variety of domains. It wouldn't be feasible to have a batteries-included stdlib for all of them. (Python historically tried, and the results have been rather famously unsatisfactory.)

Also, even network services benefit from things like OpenAPI for type safety, and you don't get that from the Go stdlib.