Theory of disagreeing (aka To flame or not to flame)

@DrizztVD1 can you put this thread in the "meta" category please?

Since I was far from a stellar example in The Thread, please take all of my ramblings below with a grain of salt; I have been doing a fair amount of reflecting, and what I write here is how I want and try to behave; as seen from the Beginner Notes thread, that isn't how it always is, and I imagine the same applies for others.
I am glad that this thread exists, to discuss how we help each other to do more of the want, and less of the is

My feeling is that the spirit of the CoC was invoked in enough requests, that it wouldn't have mattered much.
As you point out, using the authority-hammer isn't always what you want to do..

As for why I didn't follow it: once I'm emotionally involved in the discussion, I find it hard to take a step back, breathe and review my behaviour (against the CoC, or even just generally) This is the primary reason I ended up leaving and muting the thread: after being called on it twice, I realised I was too close emotionally to stay rational and polite. That's not the side of myself I want to present or encourage.

This is also why I see a valuable role for "bystanders", even if they haven't actively posted in the thread: they are not (yet) too involved, and thus in a more rational position to intervene.
I was grateful for the admonishments I received, and tried to visibly acknowledge this, in the hopes that people keep doing it, not just for me, but for everyone.
I've also edited the original posts to make sure later readers won't have to suffer the same aggressive tone (while leaving an edit-note saying so, so it doesn't look like I'm trying to evade blame)

For me, it doesn't matter if the admonisher previously posted in the topic or not. (Although to be fair, I think I would be more receptive to "established" forum members, and might even be dismissive of a user who joined an hour ago :flushed: (depending on how accurately they judged the forum's morals and customs))
One of the core Discourse philosophies is that "Reading is Fundamental". From that perspective, I personally feel that reading is participating.

Additionally, the CoC reminds us to "that itā€™s your responsibility to make your fellow Rustaceans comfortable.".
If a small group of people is loudly yelling in a thread, that is making (silently observing) participants uncomfortable. In a physical space, people would cast annoyed looks, or loudly clear their throat; in this digital space, all we have is flags and replies.
I feel that it should be OK to reply to "clear your throat", but apparently. The Discourse team (which has put far more thought into this than me) disagrees and recommends flagging instead (because replies invite discussion and "reward" the behaviour with attention)
There are flag-reasons for both "off-topic" and "something else", both of which seem to apply to quite a few posts in the Beginner Notes thread....

I read the CoC when I started drifting into Rust years ago, but before re-reading it yesterday I couldn't have reproduced anything specific.
I couldn't immediately find where the forum specifically pushes the CoC, but as it is an obviously official Rust space, I think it is fairly obvious that the CoC applies. ("Our code of conduct sets the standards for behavior in all official Rust forums.")

Additionally: Discourse proffers the Discourse FAQ to anyone at Trust-Level 0 (i.e. very recently joined members) in a big banner at top-of-page. This expounds mostly the same values, though it is easy to dismiss (which I appreciate; Discourse follows the philosophy "you can lead a horse to water, but you can't make it drink", which I find very respectful to the users)

Another thing I like about Discourse: it takes technical measures to prevent flamewars; it detects when people are replying at eachother in rapid succession with short posts, and then adds a Just-In-Time reminder on the reply window, asking if it might be sensible to take a breather for a while. (I've run into it in a (non-heated) topic before, because we were abusing it as a chatroom)
I'm not sure how something like this could apply in our current case: most posts were long, and spread out over multiple days; that would leave only automated keyword analysis to estimate "heatedness", which I don't think is really tractable. Human language(s!) are just to darn subtle...

I'm not a moderator, but I have sent private messages to address issues before, via the flag>send-private-message, and generally received positive responses.
I believe that Discourse encourages PMs to keep meta-discussion out-of-band, and to make sure criticism directed at people/behaviour do not immediately becomes a public laughing stock.

6 Likes

Speaking as a member of the moderation team: We do encourage everyone in the community to call attention to the code of conduct when needed. I agree with the suggestions that this is often best done out-of-band. And on Discourse in particular, the flagging system (or otherwise contacting the moderators) is often the best way to deal with violations. Moderators can hide or remove comments, lock threads, split threads, and respond in various other ways that can help keep things on track. One problematic post isn't too big a problem if it gets flagged and fixed quickly. It's much harder to have a useful discussion if the thread fills up with emotional reactions instead.

5 Likes

I read through the thread a few days ago and didn't find anything objectionable.

Yes, there was harsh critique of Rust and of certain APIs in Rust, but so what? I felt it was super interesting and valuable to get some fresh perspective on things from someone who had (apparently) followed the evolution of other languages like C++ and C# closely enough to have strong opinions on them. I appreciated the blunt and direct form.

The attacks on the ideas and APIs were not personal -- the were technical as far as I could tell. I don't recall seeing anything like "You [designer of String] is a complete idiot for making strings mutable". Instead @peter_bertok gave us his opinion on this aspect of the String API, and people could then decide to agree or disagree.

Even when talking about code from Ripgrep, I felt that the tone was good: to me, Peter pointed out that it's a "tragedy" that @BurntSushi had to write "so much code". Yes, the tone might have been a bit exaggerated, but this code was simply used as an example of some (supposed) lack of abstraction in the standard library. Again, I don't recall Peter saying that anybody was stupid for writing this code -- to me, it sounded like he emphasized with the need for the code under the circumstances, while also wanting to point out that with the right abstractions, such code would magically vanish.

I don't actually know if Peter was right here -- and I don't think that's the point for this discussion.

9 Likes

I agree with @mgeisler. The thread was a bit heated but I thought on technical grounds only - there was nothing personal. Itā€™s also the internet and written communication, which can oftentimes make words seem harsher than intended. Would I have liked to see the technical tone a bit more mellow? Maybe, but to each his own as long as things donā€™t get personal. I think a more mellow approach wouldā€™ve been more productive as people wouldnā€™t be distracted by the tone and immediately get on the defensive.

Ironically, the only time I felt things were heading into personal territory is when @DrizztVD1 was being questioned for breaking out subthreads.

Anyway, I think this was a good unintentional ā€œexerciseā€ for this forumā€™s community and Iā€™m sure some people will have their own takeaways from it, none of which need to be aired out necessarily.

So, letā€™s move on :slight_smile:

4 Likes

I agree that we should soon move on, but for the record I definitely disagree with @mgeisler. It's not just the tone. Often "feelings" were aired without arguments, and alternative "ideas" were presented as great solutions even though they were poorly thought through or presented in a rather imbalanced way. This corresponds to the following two rules in the CoC:

  • 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.
  • Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works.

Let me take an example post that violates the second point, and explain my interpretation. In post 5, @peter_bertok writes:

Collapsed

There is very little technically in that post. And I take this as an indirect and poorly motivated complaint that

  • As opposed to other successful languages (which?), Rust is not based on "mathematically sound theory"
  • Rust is "impure"
  • Rust is a failure (it "fell short")
  • Rust is sinking into a messy quagmire
  • Rust feels like a step backwards for everyone else used to elegant languages (again, I don't know what mainstream languages count count as elegant).
  • Rust is littered with landmines
  • The situation is getting worse
  • There is no sound underlying theory behind Rust
  • There are too many undefined behaviours in Rust

There is no need for such descriptions of Rust. They were overly harsh conclusions, and this alienates other users. It is fine if users vent negative emotions, but we should strive to use much milder words than these. And there is definitely room to use the CoC more proactively, as @BatmanAoD suggests above.

I can see that not everyone in the thread took @peter_bertok's words in the same way. I think that's fine on both sides: the community is open to a wide range of personalities. But that underlines how valuable the role can be of bystanders who do notice that people are getting offended (+1 @juleskers).

I regret having to analyse @peter_bertok's post so deeply here as I'm sure he didn't mean it poorly. But I do think violations of the CoC in that thread were common and we need to prevent this stuff from happening again. And we can.

8 Likes

I don't really feel that one can (or should) decide if people can present ideas that are "poorly thought through" based on a policy document like a Code of Conduct. People will always say things that are silly or less well-structured and that's just how conversation is -- even super friendly conversation among old friends :slight_smile:

The people on this forum are very friendly, and I appreciate this every day. However, I really hope they're friendly because they're intrinsically nice people and not because of some random document that they may or may not have read when signing up.

I think we should trust those others users to make their own conclusions about the arguments and about the language. The harsh comments are just one data point in anybody's evaluation of Rust -- there are tons of much more positive descriptions of the language.

I don't think we should try to make this forum an island of happiness where we can only speak nicely about Rust. Of all places, this should be where the language and its APIs are torn to pieces with the common goal of building something better!

4 Likes

Well it is okay for 2 people to disagree and sometimes it goes on for a long while as both "parties" try their best to prove themselve right or the other person wrong.

Any "attack" carried out in the process should be an attack on the facts and points that the person has proved, not on the person.

1 Like

What bothered me was that the creator of that thread was acting as if he was superior to everyone in the Rust community. Even if he did not personally target anyone, his tone unequivocally said "I don't respect you at all". It wasn't for nothing things like "rising blood pressure" were mentioned in the thread. Even if your frontal contex didn't see it, your body was reading his message very clearly.

8 Likes

Hmmm. Depends on what you mean by superior. I felt he was acting out his superior knowledge. I also agree that a user should feel free to give their informed opinion, even if it is in the negative. Personally, I think of it this way: if Rust is really a good language, then detractors would and should be proven wrong. This should be done in a concise manner in a way that is discoverable later, meaning that if similar arguments come up again from another user, we just point the person in the direction of the previous discussion where their contentions were analyzed and disproven.

It's important to note that Rust takes an inherently superior stance itself towards other system programming languages, as in: "why use Rust?" "Because it's better than x, y, or x". That in itself is going to buy itself enemies out there, even if one has all the facts to prove that claim.

Therefore, especially as Rust popularity grows, more people are going to come onto the forums being pre-antagonised by invective language on other sites and end up coming to the forums to prove their preconceived ideas of the Rust community's arrogance/pride (hopefully wrongly so). Note that they already think you(we) are arrogant, so they will think they are justified in fighting fire with fire. See this from their viewpoint and you'll notice that they are not bad people, just misinformed.

Most of it will go like this: "You say Rust is so much better??? That's rubbish because Python has much more support and is faster to get stuff done in, blah, blah, blah" The refrain will need to be: memory control with safety, garbage collection, and whatever disqualifies 99% (100%?) of the languages Rust gets compared with in such statements.

To deal with such cases, it is needed to throw questions at the poster to let them vent freely and fully until they are mostly done. To do this, the suggestion is to follow the Socratic questioning style, particularly with the goal of seeking first to understand. Thereafter, the Socratic Method can be used to concisely target the base level of their assumptions (usually the response question will be: "can you build a complete OS with only the language you are comparing with?)"

The last step would be to post linked replies to create separate threads on each individual topic that deserves an answer or discussion, focussing at first on pointing towards RFCs and other previous discussions to aid in reducing the amount of responding that needs to be done.

4 Likes

Do you actually find this to be true, that the Rust community, as a whole, is elitist? Because I donā€™t. There are certainly ā€œfanboysā€ here and there, but thatā€™s not unique to Rust. Every language has some motivation behind its inception, and they all make tradeoffs because you canā€™t design a one language to rule them all - the design space is too big and there are competing forces.

Iā€™ve always felt that Rust has been (and should continue to be) sold on its own merits, with clear emphasis on its goals and what tradeoffs it makes. The people that will find it attractive are the ones sharing the same values as Rust (ie agree with the tradeoffs) - itā€™s very much a ā€œif you build it, they will comeā€ situation. Thereā€™s really very little reason to ā€œargueā€ about languages, if you keep that perspective in mind.

4 Likes

Perhaps what is needed to counter this perception of arrogance is a small section in the book, and elsewhere, that lists problem domains for which Rust is currently not the most appropriate tool. Categories such as "math" (Julia), "rapid prototyping" (Python), "provably safe" (Ada/SPARC), etc. come to mind. I'm certain that others on this forum can extend and improve such a list.

4 Likes

Agreed. To clarify, when looking from the perspective of an outsider who may be misinformed about the merits of Rust, an elitist view can be misconstrued. This follows because a misinformed person will see a disconnect between the claims made about Rust by the community and what they end up seeing.

One clear misconception that we see is that, for some, the tendency is for 'elegant' or even 'simpler' languages to be better than more complex ones. This makes it obvious in a sense why an outsider can conclude "Rust claims to be better than x, or y, but is, in fact, more complex than x, or y, therefore is obviously inferior". Following the Socratic Method on peter_bertrok's posts, the central point of contention can be seen as 'elegance confers superiority', and dealing with this and only this contention should be sufficient to settle the emotional side of the debate. The point being that Rust is, relevant to its systems programming directive, relatively elegant and relatively equal to any other new shiny language, even if on an absolute basis of comparison, Rust is more complex. I hope this makes sense.

Yes and no. If every programmer could individually determine which language they choose to use, this might be true. As it turns out, economic factors play a large role, and economic decisions are often made by non-technical people. Therefore, a certain level of argumentation will be needed because adoption due to economic reasons is unlikely to occur automatically.

If you can draw up a graph and point to real-world data that shows, for example, "switching to Rust reduced our long-term product maintenance cost by 20%, even though it increased our development cost by 10%", the bean counters are going to love Rust. Meaning that you are forced to compare the status quo with Rust and then prove why Rust should be adopted as a matter of company policy. This is the reason why the Rust Whitepapers exists. The Tilde paper compares Ruby, C++, and Rust, and finds Rust superior on several metrics.

3 Likes

If theyā€™re truly misinformed then it should be relatively easy to inform them if the true issue is merely lack of knowledge, rather than reality not being consistent with the ā€œmarketing materialā€. There are also people who, deep down, donā€™t really want to become informed - they come in with preconceived notions of how Rust should work based on other languages they know, and then try to squeeze Rust into that comfortable and familiar box they know. For those whoā€™ve been around these forums long enough, Iā€™m sure theyā€™ll remember posts of this latter nature. But ultimately, Rust isnā€™t for everyone and thatā€™s totally fine.

Yes, for sure. But, I think engineers should first convince/prove to themselves that Rust is better than the alternatives, for whatever definition of ā€œbetterā€ makes sense. The debates we usually have on these forums are between technical people, and so these should be as purely merit based as one could get. Certainly once non-technical people get involved in real life situations, a whole slew of other considerations come into play.

Yes, everyone loves success stories. This is why Rust needs more of them. I (and others) have said this before: the best ā€œmarketingā€ will be Rust versions (not literally, but in terms of impact and ubiquity) of nginx, Cassandra/HBase/Hadoop/Spark/Zookeeper/etc potpourri of big data solutions, Postgres/sqlite/MySql/etc databases, redis/memcache, and so on. Right now, thereā€™s essentially nothing of the sort. We need that ā€œproof is in the puddingā€ output. Ripgrep and perhaps Servo come closest but I donā€™t think itā€™s there. Someone needs to go out and build big complex systems, and in the process demonstrate all the selling points of Rust (performance, stability/safety, and ergonomics to some extent). At this point, itā€™s mostly technical people involved. Once we have a portfolio of these, selling Rust elsewhere will be a lot easier.

And letā€™s also not forget that non-technical decision makers generally arenā€™t invested either emotionally or intellectually in what language the product was built in. They wonā€™t care if you banged something out in C++ after 1 month but spent 3 weeks being intimate with GDB and the sanitizers or you spent 3 weeks fighting the borrow checker - if the product is equally performant, stable, has all the required features, yada yada, they wonā€™t care how it got there. I know this is stereotypical and there are other considerations, but fundamentally, thatā€™s what they mostly care about. Itā€™s on the technical people to use the right tools.

3 Likes

I said that he was "acting superior", which in English has a very different -- almost the opposite -- meaning than being superior. I was neither disputing his knowledge nor contesting his right to express negative opinions. I was only questioning his tone. I welcome Rust's criticism. Mine was the first comment explicitly asking him to be heard. So I wasn't being touchy about Rust in case that's how you interpreted me.

2 Likes

Here we must appreciate the difficulty posed by such phrasing for someone who learned English in school, rather than as a "milk tongue" when they were a baby.

1 Like

I'm sorry if I conveyed the impression I was doubting @DrizztVD1's English skills. I certainly didn't mean that.

It's a good idea to be humble; I would of course come up with a different list :wink:

  • Mathematics: Agda (OK; this is not number cruching linear algebra or calculus, but rather machine checkable theorem proving)
  • Rapid prototyping: Haskell
  • Provably safe: Idris / F* / Agda / Coq

so such a list will necessarily have to be somewhat vague, overspecified, etc. in the sense that it says that some languages could be better in some domains (and also listing more than one in each category...)

Yes, everyone loves success stories. This is why Rust needs more of
them. I (and others) have said this before: the best ā€œmarketingā€ will
be Rust versions (not literally, but in terms of impact and ubiquity) of
nginx, Cassandra/HBase/Hadoop/Spark/Zookeeper/etc potpourri of big data
solutions, Postgres/sqlite/MySql/etc databases, redis/memcache, and so
on. Right now, thereā€™s essentially nothing of the sort. We need that
ā€œproof is in the puddingā€ output.

FWIW, there's Sozu [1] too.

[1] https://www.sozu.io/

1 Like

Sure, and Iā€™ve heard of sozu before. I didnā€™t list a whole bunch of other projects that I think have some potential. But, I think youā€™ll agree that sozu is not used nor known like nginx. I was specifically saying we need ā€œhouseholdā€ names.