OK, so I'll respond to what I see are the two "chunks" of your comment. The first chunk I see as "there are too many people zealously advocating for Rust." And the second chunk is, "say Rust has worse backward compatibility policy than C++, Python and Haskell instead of linking to an RFC." (I am "quoting" you here with the intent of phrasing my own internal understanding of what you're saying. The benefit of that is that if I misunderstood you, then perhaps you can correct that. It might make the conversation easier.)

So to the first chunk: absolutely. I don't really know what to do about it. You can find oodles and oodles of people with persistent misunderstandings about Rust and various aspects on both sides. Lots of people overstate what it can do, and lots of people understate what it can do. The overstatements tend to look like this:

* The Rust Project, as a whole, will literally never break your code.

* Rust's safety means that "once you compile it, it works." (A funny meme that I remember from my Haskell days. But now people also use it when talking about Rust.)

* Rust makes undefined behavior completely impossible.

Those are all overstatements. The most persistent understatement I see is, "well if Rust has 'unsafe' and everything boils down to using 'unsafe', then what's the point of Rust at all?"

I've spent time correcting all of these misunderstandings in various online forums.

I honestly do not know what the root of it is. I do not see people involved in the Rust project trying to push the overstatements. Most of the documentation materials I see maintained in the Rust project are sufficiently nuanced. It is just not obvious to me where "the Rust project is failing at communication" ends and "communication is heavily lossy and the general population is just going to fundamentally misunderstand most things because nuance has been stripped by the time the content filters down to them" begins.

I have my own mini-problems with this and ripgrep for example. Just the other day someone was trying to say that ripgrep was a "grep replacement" and so wasn't as suitable to code search as ack or ag. Like... wut? I don't see how it's possible to even skim ripgrep's README for less than 20 seconds and come away with that misunderstanding. Upon further prodding, I discovered:

* Their google-fu failed them.

* They "just assumed" from the name, because "grep" was in it.

* They were still a student and ultimately admitted they should have said they weren't "sure."

One of the most important lessons anyone can learn---especially an engineer---is to be clear about their certainty. I think it is just a fact of life that people aren't because they don't want to or maybe more likely, never learned the skill. (And it's even worse outside of engineering.) We could "fix" this by ensuring that everyone commenting online was always labeled with their experience level in a way that was true 100% of the time. Imagine if we could do that, hah. (And if we could, I'm not saying we should, but let's indulge.) I sometimes wonder just how strong the inverse correlation is between "says obviously wrong things with certainty" and "years of experience."

Anyway... sorry... Got off on a bit of a ramble there. Bottom line is that I agree it's a problem, but I don't know how it can be fixed. And there are other factors in play here, given that, ultimately, Rust really is trying to unseat some very old and very entrenched technologies. It is a complex sociological and cultural process.

OK, as to your second chunk... I want to quote the comment I was originally responding to:

> As always when I see this claim, I feel compelled to point out that the Rust team’s claim is simply not true, since they don’t regard adding new functions to existing impls in the standard library as a breaking change, even though it can make working code stop compiling or even do something different.

I am pretty sure that the ideal answer to this comment has to include some mention of our API evolution RFC. It is essential context for how we make decisions. What is less clear is that we don't really have (AFAIK) a solid written document describing how we deliberate on things that are permissible under API evolution, but break code in practice. There is a lot of grey area there. If the breakage is super rare, we might go fix that crate or issue a deprecation notice, wait some time and then make the change. That has happened. If the breakage is not so rare, then it's nearly guaranteed that we'll just drop it. Or find a way to smuggle it in over an edition boundary so that there is no breakage at all (you have to opt into it, and new Rust compilers still support the old behavior on the old edition).

I also note that in your second chunk, you go from talking about "in C++/Python/Haskell, decades old code still builds and works." But you then go on to talk about semantic stability in Rust. Why not compare apples with apples? Rust doesn't have decades of existence to leverage here.

To be quite honest, I would be very interested in analysis of actual decades old code of C++, Python and Haskell. For Python at least, we're talking about pre-2.7. And there were definitely breaking changes introduced in 2.7 when compared to 2.6. And that's just one release. For C++, they break stuff too! For example: https://stackoverflow.com/questions/6399615/what-breaking-ch...

I really truly believe that Rust is no worse than other programming languages when it comes to backcompat. More than that, I think it's better than most.