Rust beginner notes & questions

I'm really starting to like this thread, the tone has improved, I've gotten my breathing under control again, and there are lots of deep, insightful discussions :slight_smile:

(I'm on mobile, so I'll keep it brief-ish)


Utf-8 Vs utf-16: all of the systems that have chosen utf-16 has regretted this. It seemed like a good idea at the time, because it used to be a fixed-length encoding. Now that it isn't anymore, utf-8 is better in all respects.
I admire the guts windows and java showed in adopting unicode early, but history has not been kind to their "first-mover" status.
I am glad that rust chose the future-proof path with utf-8, even though this means shimming and OsStr.. and thanks to the good, generic From/Into shim traits infrastructure, that shimming will remain as simple as possible, within the limits of the existing, divergent platforms/environments


Trustworthy packaging is definitely a concern, but the infrastructure surrounding cargo is very future-proof.
For example, the entire crates.io index is a git-repository, meaning that it can be cryptographically verified. Signing this is actively being discussed (link to follow).

2-factor login for crate authors is possible if you chose to authenticate via GitHub, and there is an ongoing internals discussion on making 2FA required for publishing. (Inspired by the NPM eslint attack)

Crate signing would definitely be cool, and is only waiting for someone to put in the hours to implement it. Thanks is to the index being a git repo, the signing public key can even be distributed securely.
The crates team is strongly aware of their responsibility, and has been discussing alternatives like the cryptographically secure "TUF" since the get-go.
Their security-mindedness inspires a lot more confidence in me personally than the ad-hoc-ish track record of NPM (and with NPM community board member Ashley Dubs being a prominent part of the Rust team, you can bet that the NPM lessons are not lost on Rust)

Crate discoverability is indeed not yet optimal, and this is known in the community and in the team. See for example the current experiment with crates.rs (Todo:link)

Searching and ranking is being investigated, it since it's mostly a social problem, not a technical one, we are talking "harder-than-NP-hard hard"....

4 Likes

With regard to the crate discoverability complaint, crates.rs (announced on this forum here) makes a good attempt at improving this in a highly performant way.

Adding a maintenance quality metric to the ranking algorithm would probably address the only complaint about the crate ecosystem that it does not already address. Something like checking that it compiles with latest stable compiler first. If it compiles then it is given a maintenance score of 1.0. If it does not compile with latest stable, score should be reduced according to date of last version update -- 0.9 if the last version was a month before the last compiler update, for instance, but 0.1 if the last version was two years ago. Use this score as a multiplier for the current "popularity" index.

2 Likes

I know I can sound... harsh, but it's "tough love". I like the Rust project and I want to see it succeed, because C++ is long overdue to have real competition.

I think what a lot of open source projects are missing is someone loudly saying "No!". Too many people patting each other on the back for a "job well done" when the job isn't done leads to very happy people pleased to produce something that ultimately is a failure when faced with reality.

For an example of how open source can work, look at Linux. In my humble opinion, the single most important thing that makes Linux successful is Linus Torvalds. He's brutally harsh in his feedback, infamously so. People constantly criticise his language, when he is simply stating facts. Often these are uncomfortable facts people don't like to hear, but must hear to have any chance at success. Some bars are set very high, such as "entry into the kernel", but people are sloppy and lazy. Linus points out that this is unacceptable. People don't like it, but that's not the point, because the computer doesn't care about you feel about the quality of your code.

The rust-lang forum helpfully suggested some related topics, which shows that I'm certainly not the only one with such issues:

To give an example, on Saturday I tried to read and write from a TcpStream using a buffered reader and buffered writer. Using the examples in the docs this was impossible because once the writer was constructed the reader could no longer use the stream.

This kind of "difficult to assemble layers of stream processing" commentary ended up being the bulk of this topic...

And, a topic created by yourself:

I’m trying to learn Tokio and finding it too complicated. The problems for me are:

  1. The sheer number of types involved.
  2. Choice of names for the types is such that they don’t indicate the intent clearly.
  3. Also at a coarser level, many things seem non-intuitive. For example, why is a ServerProto, which is meant to represent a protocol, creating a transport? There are many such design choices which are non-intuitive.

Also a very similar point.

I see a bunch of people are politely saying the same thing over and over.

Has it worked?

Rust is, what, 8 years old now, and the 1.0 release was 3 years ago! Yet it is still obscenely difficult to do really basic things with the language, like read and write a socket. Please excuse my language when I say: "What-the-f***!?"

2 Likes

The main problem with brilliant jerks such as Linux Torvalds is that they are not composable.

Put one of them in a room with a polite person, and they will quickly exhaust that person until she leaves.

Put two of them in a room, and hell breaks loose as they start yelling at each other over the most trivial matters.

Ultimately, having a brilliant jerk around greatly limits your ability to assemble significant amounts of manpower, which is the name of the game in software.

Complaining, whether politely or impolitely, is ultimately a very ineffective way of moving things forward in a software community. If you really want something done, the most effective way is almost always to go and do it yourself.

Time is too precious a resource to expend sizeable amounts of it in Internet arguments.

19 Likes

The Rust project specifically rejects the idea that you must be mean in order to give feedback. It’s not only a moral thing; it ends up distracting from the actual feedback, making it harder to sort out what’s vitriol and what can actually be done to improve things.

See this very thread. The extra arguing has made many, very offtopic comments, rather than actually figuring out what could be done to improve things. It took a while to get back into the topic.

Criticism: good. Being a jerk while giving it? Not good.

28 Likes

As Hadrien and Steve have already pointed out, we are trying emphatically to avoid having "loud" dictators in the Rust World.

Obnoxiousness alienates, and not even a truly brilliant, won't be seen for another thousand-years genius, can outcompete a dozen people of "only normally smart" level, but who are working together at a normal, pleasant blood pressure level.

Tokio composability has been the singular focus of the hugely-breaking 0.2 rewrite, with gigantic usability improvements.
Another equally big leap forward is to be expected after impl Trait.
So obviously"people politely repeating requests" has done exactly what was required, with a pleasant experience for the implementors, who will stick around because of it, and still enjoy improving their work, rather than taking their ball and going home because their first API design (in a revolutionary, never-seen-before ownership-based environment, where no established wisdom exists) was "criticised" with slurs. (Edit: deleted uncalled for criticism of other communities by name, thank you for calling me on it @burntsushi)

There is a reason I am a rust-enthusiast, and the excellent examples of good behaviour (unfortunately not my own...), are a large part of it.

12 Likes

@juleskers I'm strongly in favor encouraging others to work together respectfully, but let's do it on our own terms and avoid unstructured critique of communities/projects/individuals that work differently than us. Not only is it uncouth, but it's just going to inspire more off topic debate instead of focusing on what's important: in Rust spaces, we're kind and respectful to each other.

I'm hopeful that further discussion in this thread can be productive. Enough folks have reminded @peter_bertok to be kinder with their words. Let's try to avoid further meta discussion.

7 Likes

I'm just an outsider looking in, with no skin in the game. Feel free to ignore me. 8)

Pease allow me a chance to clarify the (very off-topic) point that I was trying to make, I don't want to be seen as advocating for more rudeness, because obviously that's not constructive...

My entirely unscientific observation over decades is that successful languages seem to be usually designed by surprisingly few key people, providing "a clear design direction", at least initially. E.g.:

  1. C - Dennis Ritchie
  2. C++ - Bjarne Stroustrup
  3. Python - Guido van Rossum
  4. Perl - Larry Wall
  5. Java - James Gosling
  6. Ruby - Yukihiro Matsumoto
  7. JavaScript - Brendan Eich

I agree with you that Linus-style leadership is probably not the best example to use, because he can definitely rub people the wrong way. So instead, consider the list above, because it's more apt to Rust anyway. Are any of those people rude? Brash? I don't think so, or at least not infamously so, like Linus. Still, I would argue that their clear leadership was required for the success of their languages.

Notably, most of those languages have changed over time, being taken over by cooperating committees or communities with no clear leadership. In particular, C and C++ have stagnated and wandered around aimlessly for over a decade because of the incompatible requirements of the various vendors all having their say.

It's entirely possible that Rust can develop to be a successful, widely used language that isn't relegated to some specialised niche. I'd love it, if this happened! I'm also watching the community-driven process with absolute fascination. Maybe it can work! It's certainly educational to watch it all unfold in real time. To my knowledge, no mainstream language has ever started out community-driven and succeeded. Maybe Rust can pave the way...

A side-note on tokio improving: coincidentally, this was just posted today:

In particular, this bit is impressive:

For a long time, many users have asked for us to remove the Error type from Future, because they did had a non-IO use case in which the Error type was inappropriate. We’ve come around to agreeing with them; having the Error type would require that async functions always return a Result, and would not enable non-IO use cases for asynchronicity (such as lazily & concurrently evaluated pure computation).

So in this case at least the community process seems to have worked! The "pollution" of the Future trait with std::io::Error was one of my main issues with its design, and it seems that similar feedback by others with a similar opinion has had positive impact. 8)

However, note this warning from a post about the announcement: Be careful with this. I'm not saying you should not do it, but consider you'll h... | Hacker News

Languages like Python, Perl and JavaScript have been taken over by their open, anyone-can-contribute module systems and usually this has resulted in an absolute mess. I'm just a bit concerned that Rust is headed down the same path, and that this is hard to see during the honeymoon phase when it hasn't yet scaled up to the point that it has 8 different incompatible async I/O libraries like Python...

4 Likes

Rust didn’t start out community-driven either - it was a single Mozilla researcher’s “pet” project. It’s important to keep in mind that when the languages you listed started out, it was hard to impossible to have a community; internet wasnt as ubiquitous as today, let alone enablers like Github. If they were then perhaps those languages would’ve evolved differently as well, possibly for the better.

I also don’t think Rust is as community driven as you make it sound. There is a core team, that while open to outside opinions and contributions, ultimately decides on changes and steers the ship.

4 Likes

Yes, it has. Very, very resoundingly, it has. You just need to compare Tokio when I made the above complaint and what it is now.

(And this is my last comment on the off-topic topic)

2 Likes

Thank you for calling me on my bad form, I've removed the uncalled-for community-namecalling from the post. In retrospect, it even detracted from the point I was trying to make.

Since this is the second time I've broken courtesy on this thread, I obviously can't handle the heat here. I'm excusing myself to go look for the mute button.

1 Like

Your input is clearly valued by the Rust community. What is needed, however, is to turn your views into actionable points that can be utilised to improve the direction of Rust. Prior to the 2018 edition release, this discussion is rather pertinent.

  1. Please consider writing up pre-RFCs or whatever on a handful of the most important additions and modifications (actionable detailed items that can be executed) that would be needed to ensure that the dystopian future of incompatibility of Rust packages you described does not happen. That will serve to turn your knowledge into practical currency to further Rust constructively.

  2. I disagree that a single individual/core team is necessary to drive a successful language, instead, a unified vision and mission-statement is required. In addition, the willpower needs to exist to realise that not everyone can be satisfied with one single language and that that, sometimes, calls for a certain feature/change should be rejected purely on the grounds that there are already viable alternatives that are better suited to some people's needs - especially if this feature/change is not aligned with the chosen mission statement of Rust lang.

Focus on a common vision is imperative to ensure that a common focus is maintained in the core community since doing a few things extremely well is repeatedly shown to be better than doing many things averagely. The Rust roadmaps have shown to be a good solution to unifying the community, and could perhaps eventually morph into an overarching "Rust will always do x,y,z well, and anything that subtracts from that is not ok".

Your points on side-channel attacks on Cargo is highly relevant to the perceived Rust vision of security and can be said to be a viable core focus of Rust. Why not develop the counter-measures further and lead the improvements?

6 Likes

Just a reminder that this more general thread has sporned a more targeted thread for exploring some concrete improvements on the IO front:

I'd suggest crating separate topics for other specific improvements so people can give more targeted discussion. :slight_smile:

2 Likes

Totally OT, just can't resist:

I see what you did there :smiley:

2 Likes

Sporned? Is that where you use a "Spork" to dig out of the morass? :wink:

Sometimes my dyslexia gets the better of me! :slight_smile:

3 Likes

Sorry to add to the meta chat, but I think this point is extremely important, and all the previous reponses to it have been rather abstract, philosophical or second-hand, so I feel the need to add a more concrete "lived experience" response.

This sort of attitude immediately drives me away. I would never consider contributing to Linux because I simply don't want to deal with the kind of people who think "simply stating facts" is impossible to do without "sounding harsh". That's not constructive. That's not fun. That doesn't inspire anyone to do their best work. I've already wasted far too much of my free time on internet communities (programming and otherwise) that devolved into a toxic mess because they tolerated this sort of attitude.

In this particular thread, I basically stopped looking at your posts after the first half dozen or so, because I couldn't even figure out what you were trying to say and it was raising my blood pressure. So instead, I skimmed everyone else's responses to see if they'd managed to extract any genuinely interesting ideas from beneath the vitriol, but even that failed to impart anything useful to me because so much text was wasted on responding to the vitriol itself.

In contrast, Towards a more perfect RustIO has been constructive all the way through, so now I finally understand what you were trying to tell us, and I'm still happily reading everyone's posts over there. So congrats to the amazing community here for turning that around so completely, and let's try to focus on that thread now.

25 Likes

Just another voice who is here because I simply won't be anywhere jerks (to be kind) are tolerated or even lionized. A number of other open source projects have variously admired or envied Rust's phenomenal growth. It is because Rust welcomes and makes comfortable more than just the hostile-by-default.

1 Like

OK so as this meta-thread looks like it's not going to die, a few
comments on it that I've been refraining from putting out so far.

There are two kinds of jerks. The one who attacks individuals, and the
one who attacks the language (in the present case).

I haven't read the whole thread, only ~10 days of it. But I've only seen
@peter_bertok being a jerk against the language. On the other hand, I
have seen attacks (at least one that couldn't be miscategorized for
anything else and has been flagged, but others that felt like it to me
too) against @peter_bertok personally.

In my opinion, harsh attacks against the language are OK. Harsh attacks
against individuals are not.

And the reasons why I think harsh attacks against the language are OK:

  1. If someone at the commands of the language attacks it, it won't be
    harsh, it'll be loving
  2. Hence, only people that have relatively little influence in the
    community can be harsh against the language
  3. Which means that they can just be ignored (in opposition to eg. Linus
    who couldn't be ignored because he is at the helm of the kernel)
  4. And so these persons' feedback will at best be read by someone and
    acted upon, and at worst be ignored
  5. Oh, and if we feel personally offended when our favorite language is
    attacked, maybe that means it's time to stop writing Rust for a bit of
    time and get some air :stuck_out_tongue:
7 Likes

I'd prefer to see a devolving thread split (asap) into multiple topics and the conversation/debate continued on their respective dedicated threads. I'd like @peter_bertok and others to spawn topics off of this thread and link to them to try and reach a consensus on the debates.

Fundamentally, we have a "let me prove to you Rust actually sucks at several things" debate in this thread.

1 Like