I can’t deny that the current design of Rust is very inspired by C++, and there are certainly areas where (as you say) I wish Rust went further than it currently does, though I think “C++ 2.0” doesn’t quite do Rust justice.
On the other hand, UTF-8 is very common on Unixes and with network code, so choosing UTF-16 isn’t correct either.
You are right that it would be great if Rust had a more generic system for handling strings (including different encodings).
Isn’t that more of a failing of C++, rather than a failing of package management in general? As long as Rust has a rich set of blessed libraries, isn’t that equivalent to having a rich stdlib?
However, I wasn’t saying that Rust docs are good and other languages aren’t. I was saying that because Rust docs are good, that makes crates more similar to the stdlib. Of course that also applies to other languages that have good docs.
My goal has always been to make good arguments, not to win arguments, so I consider that a compliment.
Those are all good points, which I think can be solved by the community: crates.io listing actively maintained crates, putting more statistics on crates.io, using more badges, etc. There’s actually been some discussion about that recently. I think there’s definitely a lot that can be improved!
I’m not sure if that’s a good counter-argument. In any system with third-party packages you can find bad code. My point was that the popular crates should be roughly the same quality as the stdlib.
As for some of your specific points: I think a lot of it can be solved with lints, and tools that can analyze an entire cargo dependency tree to display useful information (such as the amount of unsafe code, etc.). There’s also work being done on a “portability lint” that should improve the situation that you mentioned with 32-bit vs 64-bit (among other things).
I’m 100% with you about the suckage of npm, though I would like to point out that Rust’s design, Cargo’s design, and the overall Rust culture and ecosystem isn’t the same as npm, so I’m cautiously optimistic.
That would have dramatically delayed the release of Rust 1.0, so I think it’s unrealistic to expect them to have been there from the start. Once things settle down and people have more bandwidth available, there’s certainly the possibility of improving things!
Let me address some of your specific suggestions:
I assume you mean some sort of hash/checksum? That sounds perfectly reasonable to me.
Why does this matter? When you publish a crate, the entire source code gets uploaded to crates.io, so there’s no connection at all to GitHub.
I strongly agree with this. It should really work like GitHub: user-name/package-name.
Doesn’t a namespace system basically remove the need for GUIDs?
I agree with this, though I suspect it’ll be quite difficult to do it right.
This is already implemented and working on crates.io. In fact, it even displays a graph showing the number of downloads over time.
I haven’t tested it, but I believe it’s possible to use semver for that, e.g.
As for seeing whether transitive crates are pre-release or not, that sounds like a good idea (and not hard to add).
It’s not automatic, but crater does get run pretty regularly.
Of course individual crates can use continuous integration (like Travis), and many do.
I imagine it’s just because nobody’s done it yet. You have to keep in mind that Rust is still a small community, so we have to prioritize our time and energy. So a lot of “nice-to-have” features end up being passed over in favor of “we-need-it-now” features.
For applications there’s the
Cargo.lock that prevents that, though I agree that it’s very scary for new applications.
Just FYI, Nix solves pretty much every problem you listed, it’s a super fantastic package manager, and they do have support for Rust. Unfortunately Nix doesn’t have great Windows support right now.
So, given that Nix was able to solve those problems, I think Cargo can solve them too, it will just take time and effort (which is in short supply right now, because of the imminent release of Rust 2018).