Rust beginner notes & questions

[Pauan]

@peter_bertok

Once you learn enough languages, and have sufficient decades of experience under your belt, you can get very good at spotting the “accents” of other developers. My main complaint with Rust is that most of its core developers have a strong “C++ accent”. In my mind, Rust 1.x isn’t Rust enough . You can argue all you want that I’m wrong about this, but to me it looks like C++ 2.0 from a mile away.

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.

@peter_bertok

I don’t like that UTF-8 as a memory layout was basically forced on everybody, when UTF-16 is still all too common with Java, C#, and Win32 interop – none of which is going away any time soon. This is the same mistake the Haskell guys made by forcing a specific string implementation on people when it was clearly wrong. Strings are complex enough to warrant an interface.

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

@peter_bertok

A thin standard library is one of the reasons I abandoned C++. My productivity in other languages is at a minimum 5x better than in C++, and most of that is due to the richer libraries available out of the box.

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?

@peter_bertok

Unless you mean C or C++, documentation isn’t exactly uncommon… Even there, documentation is often quite good, I used to use Doxygen back in 2001 or so along with many other people. Standardised “comment-based docs” are over 20 years old now, both Java and C# 1.0 had this.

In my experience the quality of Rust docs are quite a lot better than other languages I have used (including Python, F#, C#, and JavaScript).

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.

@peter_bertok

I like that you play devil’s advocate to your own post, that’s very scientific of you. 8)

My goal has always been to make good arguments, not to win arguments, so I consider that a compliment.

@peter_bertok

Maintenance: [...]

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!

@peter_bertok

Poor Quality: [...]

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

@peter_bertok

Incompatibility: [...]

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.

@peter_bertok

the following features at a minimum really ought to have been included in Cargo from day #1

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:

@peter_bertok

Code signing or some sort of method for securely verifying the origin of code.

I assume you mean some sort of hash/checksum? That sounds perfectly reasonable to me.

@peter_bertok

Some clear – or better yet – enforced way to verify that what’s on GitHub matches what’s on cargo.io.

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.

@peter_bertok

Some sort of namespace system to avoid typosquatting,

I strongly agree with this. It should really work like GitHub: user-name/package-name.

@peter_bertok

Some method to handle renames of crates, such as using GUIDs as the real crate identifier, and the display name used only during the initial search.

Doesn't a namespace system basically remove the need for GUIDs?

@peter_bertok

Compatibility flags on all crates, such as the required rustc version, std or core compatible, 32-bit or 64-bit, x86 or ARM, SSE2 or AVX, etc, etc…

I agree with this, though I suspect it'll be quite difficult to do it right.

@peter_bertok

The popularity of a crate (number of downloads, etc…) so you can judge how many people use it.

This is already implemented and working on crates.io. In fact, it even displays a graph showing the number of downloads over time.

@peter_bertok

Whether it is prerelease or not, including all transitive dependencies.

I haven't tested it, but I believe it's possible to use semver for that, e.g. 3.0.0-alpha

As for seeing whether transitive crates are pre-release or not, that sounds like a good idea (and not hard to add).

@peter_bertok

Automated builds or unit tests vs various rustc versions, verifying compatibility.

It's not automatic, but crater does get run pretty regularly.

Of course individual crates can use continuous integration (like Travis), and many do.

@peter_bertok

Why is this extra thing necessary? Why doesn’t crates.io already have this as a built-in feature? Why can’t creates have some sort of “official seal of approval”? Why can’t we determine if it’s safe to include a crate without having to trawl through web pages manually?

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.

@peter_bertok

How do you know that some 3 year old block of code you pick up and compile hasn’t suddenly been p0wned via some transitive dependency?

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