It has been longstanding policy of the project itself to take this stance. That doesn’t mean that every single community member follows our example, though, or that everyone involved is perfect. But we made a deliberate decision to try and avoid this as much as possible.

Part of this was informed by my past experiences…

I mean, come on. Are you on a bunch of Slacks? At least one of them has a :resf: emoji. It's not just random Rust users; there are people deeply involved in Rust itself that disparage other languages. Maybe that's gotten better recently, but, again, come on: look at the "About" section on this project --- which is a great project! --- and how it talks about C/C++. I happen to think Rust people are correct about C/C++, despite loving in my bones how it feels to write C code. But that doesn't mean I have to pretend that there's a real norm in the Rust community of respecting other languages.

To me, this whole thing about Rust and its decorum in language debates reminds me of those projects that don't have codes of conducts, but instead a "be excellent to each other" policy. I believe what you're saying is something the Rust project wants to be true. But that doesn't make it so!

I say this with love as someone looking forward to the next couple thousand lines of Rust I'm going to have to write at my job.

I'm not on basically any Slacks, no. "RESF" is a meme, and it's a meme for a reason. There is far more complaining about it than it actually existing. I actually got halfway to publishing a quantitative analysis on this...

What do you think is disrespectful about the about page? Maybe this is like, part of where we differ. Stating facts plainly, and talking about tradeoffs isn't disparaging. This is an engineering discussion. This isn't contempt culture. This isn't some sort of "JavaScript is shit and anyone that uses it is an idiot," which is an attitude that is a problem and is corrosive. The about page doesn't even say C and C++ are bad languages! It says that characteristics of them make it unsuitable for a specific kind of application, due to requirements that they believe are important. That's it.

And yes, I do believe that it is something that the project and project leadership wants to be true, that is less true the further you get away from the project itself. We do not have the power (nor the desire) to control what every single person says on the internet. It is about leading by example. We do not make language comparisons in official marketing or documentation, when people show up and are flamebait-y and disparaging of other languages, we tell them "hey we don't do that here" and ask them to cut it out. To me, this feels very, very different and better than a lot of language spaces. YMMV.

The page literally includes the words "Using C and C++ is bad for society, bad for your reputation, and it's bad for your customers." This is not a good hill to die on.

To be fair, that sentence has linked information, that apparently no one is reading when complaining about it.

"bad for society" => "WannaCry cyber attack cost the NHS £92m as 19,000 appointments cancelled"

https://www.telegraph.co.uk/technology/2018/10/11/wannacry-c...

"bad for your reputation" => QualPwn vulnerabilities in Qualcomm chips let hackers compromise Android devices

https://www.zdnet.com/article/qualpwn-vulnerabilities-in-qua...

"bad for your customers." => Israeli Software Helped Saudis Spy on Khashoggi, Lawsuit Says

https://www.nytimes.com/2018/12/02/world/middleeast/saudi-kh...

Now lets get back complaining about the semantics of the sentence.

The complaint isn't about the semantics, but about it furthering an image of the Rust community that's working against it when it comes to actually fixing this. Being "right" is less effective if you are being insufferable about it.

Actually it is the security community, Rust isn't alone on this endeavour.

"Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."

C.A. Hoare stated on his Turing award speech done in 1981.

I can relate to other remarks or papers from memory safe systems programming all the way back to 1961, when Burroughs B5500 was released.

Yet many keep not paying attention, like Microsoft bosting 70% memory corruption issues on one side, while selling Azure Sphere security pitch having only C as available language, or bosting the use of C++ on WinUI, among many other examples.

70% of CVEs (bugs detected) being memory related does not mean that 70% of all software bugs are memory errors (bugs that exist). See survivors bias. Memory errors can be detected with the assistance of programs, so they are much easier to find than other bugs like logic errors, which require knowing what a program ought to do. I think the latter is much more insidious.

Sure, but not particularly relevant to how the Rust community is perceived. Well, maybe, if people think you are more insufferable about any topic than the infosec community, that is actually kind of impressive.

The about page? https://www.memorysafety.org/about/ That phrase isn't on the page linked in the story either.

I fully agree that sentence is terrible. I did not see that when making my comment.

Is it terrible? Which part of it do you disagree with? I agree with it entirely.

I think it is far too broad to be taken literally. I also think, regardless if it's true or not, it's phrased in too combative of a way to be actually useful. Even if one does believe that this is true in all cases, presenting it this way isn't likely to help achieve that goal, and thus, it's a terrible statement. Finally, talking like this about technologies tends to beget an attitude and culture that ends up being unable to evenhandedly evaluate engineering tradeoffs. This makes you miss certain advantages, even in new technologies you may not like overall, which means you can't take advantage of the good parts.

It's on, "https://www.memorysafety.org/docs/memory-safety/"

Thanks.