Rust beginner notes & questions

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: https://news.ycombinator.com/item?id=17536912

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

+1.

I agree with your reasons, but I only think harsh attacks on the language are okay to some extent. @peter_bertok seems to be suffering from a fallacy that I see a lot in people in the Haskell community, and for which I have a particular distaste. Namely: the idea that you just think hard enough about something in computer science, and then you “solve” it. Examples: how to do strings, streams, kinds of abstraction.

This is a fallacy. Computer science is not like mathematics where problems are precisely defined (and even in mathematics that is disputable). There is no “best” solution between, say, UTF-8 strings and a trait as the basic abstraction. Same for everything else.

This particular fallacy is listed in the code of conduct:

Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer.

And while we should forgive @peter_bertok for not having the code of conduct present in mind all the time, I think we should not allow such discussion to continue for such a long time and just shut it down. We may lose a bit of input by shutting this down earlier, but I don’t think it really matters because nicer people will eventually come anyway and make the same points. (And those nicer people might have stayed away otherwise!)

9 Likes

That change of tone and spawning to a new thread has already occurred. See Towards a more perfect Rust IO

3 Likes

I want to clarify that I in no way was referring to @peter_bertok in my post. I was simply responding in opposition to his view that jerkish behavior might be anything but counterproductive.

2 Likes

(WIP - covers post 1-66 wip doc) There are a number of suggestions and contentions spawned by this thread, attempting to aggregate and spawn new posts combining them by topic:

Subtopic: Subsubtopic: dereferencing and strings (especially interop)

Subtopic: Subtopic: Loop syntax

Subtopic: Rust compared to C#

Subtopic: Subsubtopic: Box<Trait>

Subtopic: Setting an example: Rust code to learn from

Parallel to: Towards a more perfect RustIO - #48 by peter_bertok

Subtopic: Subtopic on std-lib thick vs thin

6 Likes