Rust beginner notes & questions

[peter_bertok]

That's a long post, I'll try to it justice by replying to as many of your points as time allows:

@Pauan

Debating technical merits (or demerits) is fine, but I noticed a theme in some of your posts, which basically goes like this: “The Rust team are a bunch of grizzled old C++ hackers who’ve never used an actual modern language, so therefore Rust has failed to incorporate the awesome parts of modern languages, so therefore Rust is basically just C++ 2.0 (and therefore has bad APIs).”

Recently I had a funny experience, where I spotted someone writing some PowerShell from across the room, but too far away to actually read their code. I could tell from the colour scheme that it was the PowerShell ISE screen, but nothing else specific. I could tell -- from that distance -- that they were a former VBScripter writing scripts exactly like they used to before, except in a new language. They hadn't embraced any of the PS "way of doing things", they were just writing their old VBScripts in the new syntax. On closer inspection, my suspicions were verified, the script they were writing looked like it had been mechanically translated line-by-line from a VB script, despite being new code dealing with Office 365 automation.

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.

@Pauan

This has even happened in Haskell! It’s commonly acknowledged that Haskell should have used the Text type rather than the String type , but this is basically impossible to change: the stdlib (and by extension a large amount of Haskell code) relies upon the String type.

Yes! This is why I don't like the current String and str types, especially that the latter is a built-in type like i32 despite being rather complex under the hood. 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.

Rust should have used a set of string traits only, and set things up from the get-go to be 100% smooth across a range of string encodings, including special cases such as &[char], Iterator<char>, compressed strings , UTF-16, Win32 Latin1, etc...

This doesn't mean that the standard library has to implement every possible encoding, just that it should have prepared the ground for libraries or std v2.0 to fill the gaps. Right now, things are... a mess. In an earlier post I highlighted issues such as a.foo(b) working but b.foo(a) failing to compile. This is the tip of the design iceberg. It may look small, but it says a lot about what's going on under the water. Crates won't fix this.

@Pauan

It’s often very hard to predict in advance which APIs are good, and which APIs seem good now but will become bad later. So rather than having a large stdlib (which is known to be bad), Rust instead takes the opinion that the stdlib should be as thin as possible , with as much functionality as possible put into crates.

Someone mentioned that this slim std-lib decision was a necessary evil to ship Rust 1.0, and this limitation has been incorrectly embraced as a virtue by many people. 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.

@Pauan

And unlike in some other languages, Rust has a strong culture of crate authors actually writing docs in the first place .

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.

@Pauan

So, these are the only downsides to third-party crates:

1. They might be less maintained.

2. They might be more poorly written (assuming the Rust language team are better programmers than the average crate author).

3. There might be multiple incompatible crates that accomplish the same task.

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

However, to add the "peer review" aspect to that scientific bent:

• Maintenance: In my experience with all third-party module systems such as cargo, or npm, or whatever is not so much that the maintenance is hit & miss, but that this is not self-evident. How do you know if a module is maintained or not? How do you know that if there is a tiny but critical problem that you can get pull request merged without actually trying? How do you know that despite a 10-year history the dev has recently gotten a new job and has put tools down? This is bad enough if you pull in a large dependency such as actix or diesel, but what about all the transitive dependencies? Are they all high-quality? Production-ready? Safe? Maintained? Future-proof? Consistent with other transitive dependencies you'll be pulling in indirectly via other crates?

• Poor Quality: This is a much bigger deal than it sounds. For example, several people have pointed out that short of reading through all code of all transitive dependencies, you have no idea if there is unsafe or panic somewhere in an innocent-looking library that will crash your application process. Neither rust nor cargo properly handle this. Oh sure, there's the unsafe keyword, but this isn't "bubbled up", like with C# where you have to mark the entire library as "compile with /unsafe". I just discovered that the mmap crate doesn't support 32-bit! Err... what? Compared to random landmines like that, I know that Rust's std library has been tested with 32-bit. I know that Microsoft has tested C# with 32-bit. How do I know that every transitive dependency will work on 32-bit platforms if 99% of Rust developers are using 64-bit operating systems to develop their crates?

• Incompatibility: This is just goint to get worse. Even some trivial modules are pulling in a dozen or more dependencies, and those in turn are pulling in more, which in turn... ugh. The NPM fiascos have shown that this just leads to madness at scale.

I have a feeling that module systems like cargo.io simply don't scale as currently designed. There's a honeymoon period that just doesn't last once the real-world kicks in. Based on just observing the mess that is NPM, the following features at a minimum really ought to have been included in Cargo from day #1, but apparently stability and safety just aren't priorities right now for a language aiming squarely at web developers and systems programmers:

1. Code signing or some sort of method for securely verifying the origin of code.
2. Some clear -- or better yet -- enforced way to verify that what's on GitHub matches what's on cargo.io.
3. Some sort of namespace system to avoid typosquatting, and random low-quality crates permanently taking every common dictionary word. There really ought to be an "official" rust library prefix, at the very least. E.g.: rust-std/uuid or instead of just uuid, which could be anything written by anyone.
4. 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.
5. 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...
6. The popularity of a crate (number of downloads, etc...) so you can judge how many people use it.
7. Whether it is prerelease or not, including all transitive dependencies.
8. Automated builds or unit tests vs various rustc versions, verifying compatibility.

Some people in this thread mentioned that both Java and C# are going down the same path with things like NuGet. In my opinion, this is terrible for the future of those languages. The quality has taken a massive nosedive. I never had to worry about the compiler throwing random internal errors with C# before, but I do now. I recently had to try and work out why a transitive dependency was causing dotnet core to fail, and I basically couldn't work it out after weeks of research. Other people hit the same dead end.

@Pauan

I think it would be a good idea to have a website somewhere that lists all of the “blessed” crates, to make it easier for Rust beginners to acclimate themself to the Rust ecosystem: right now a lot of that knowledge is locked within people’s minds.

That! That is the crux of the problem! 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?

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?

Is this the future of Rust? I suspect so..

HackerNoon - read, write and learn about any technology

52% of All JavaScript npm Packages Could Have Been Hacked via Weak Credentials