4 ms·

> All too often with Rust you get GP (who writes some of my favorite software and in general I deeply admire and respect) and some version of “no, Rust doesn’t

> All too often with Rust you get GP (who writes some of my favorite software and in general I deeply admire and respect) and some version of “no, Rust doesn’t break point releases, it’s you that doesn’t understand what ‘break’ means”. That's not what I said. What I said was to clarify the situation and to note that actual practice matters. I explicitly talked about the different meanings of "break" and acknowledged both of them as valid. And yet your portrayal of what I said makes it looks like I'm playing definitional games. I fucking hate definitional games. I do not play them. I am not saying "that's not what it means" and then sticking my fingers in my ears and saying "la la la I can't hear you." What I'm saying is that there are multiple meanings to the word and talking about those meanings is a requirement for untangling the knot. So when the libs-api team talks about "not breaking code," we do actually mean that in the literal sense. We care about not breaking code even if the change is compatible with our API evolution policy. But we still need a policy to outline what kinds of changes we can make because some of those changes can break code. The intersperse method the others brought up is a perfect example of this. It's a change allowed by our API evolution, but we've specifically held back on it because it literally breaks code.

benreesman 4y ago
So I appreciate you replying and I hope you believe me that I am in fact a big fan. I use your software every day and have read a lot of it, so I know you’re a very serious hacker and I care about your opinions. It’s not my intention to misquote anyone, especially someone who I respect a great deal, and I apologize to the extent that I have. I think the disagreement is much more about tonality than the critical importance of the details, for context: I’m a former Rust hater who became a reluctant Rust advocate when I learned (a modern iteration of) it well and would like to be an enthusiastic Rust advocate. For every comment thread where I lose my temper with some of the more, zealous, Rust advocates you can find three where I’m advising someone to look at using it or arguing with the C++ or Haskell folks that they are being unfair to Rust. My main obstacle to being an enthusiastic Rust advocate is (what is, in my opinion) a self-defeating extreme of enthusiasm and tribalism around Rust most concretely manifested in a “one language” philosophy. Rust is very cool, and probably the best low-cost abstraction / performance-sensitive language with meaningful traction today. But C++ has a place, and Python has a place, and Haskell, etc., etc. still have a place. One key example of where C++ and Python and Haskell have a place is that code still builds and still works after decades. This is a weak point of Rust: today a modest weakness, very recently a glaring weakness. So even if I misquoted you in particular: a mistrust around the semantic stability of Rust is a completely legitimate and merited concern, and it is not helped by saying anything other than “yeah, we’re less backwards compatible than alternatives, that makes sense because X”. As someone who wants Rust to succeed (what 25-year C++ veteran wouldn’t): with the utmost respect, I strongly implore you to say that instead of bringing up an RFC.
- burntsushi 4y ago
  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-changes-are-introduced-in-c11 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.

benreesman 4y ago

So I appreciate you replying and I hope you believe me that I am in fact a big fan. I use your software every day and have read a lot of it, so I know you’re a very serious hacker and I care about your opinions. It’s not my intention to misquote anyone, especially someone who I respect a great deal, and I apologize to the extent that I have. I think the disagreement is much more about tonality than the critical importance of the details, for context: I’m a former Rust hater who became a reluctant Rust advocate when I learned (a modern iteration of) it well and would like to be an enthusiastic Rust advocate. For every comment thread where I lose my temper with some of the more, zealous, Rust advocates you can find three where I’m advising someone to look at using it or arguing with the C++ or Haskell folks that they are being unfair to Rust. My main obstacle to being an enthusiastic Rust advocate is (what is, in my opinion) a self-defeating extreme of enthusiasm and tribalism around Rust most concretely manifested in a “one language” philosophy. Rust is very cool, and probably the best low-cost abstraction / performance-sensitive language with meaningful traction today. But C++ has a place, and Python has a place, and Haskell, etc., etc. still have a place. One key example of where C++ and Python and Haskell have a place is that code still builds and still works after decades. This is a weak point of Rust: today a modest weakness, very recently a glaring weakness. So even if I misquoted you in particular: a mistrust around the semantic stability of Rust is a completely legitimate and merited concern, and it is not helped by saying anything other than “yeah, we’re less backwards compatible than alternatives, that makes sense because X”. As someone who wants Rust to succeed (what 25-year C++ veteran wouldn’t): with the utmost respect, I strongly implore you to say that instead of bringing up an RFC.

burntsushi 4y ago
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-changes-are-introduced-in-c11 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.