6 ms·

I don’t think there is any confusion around the lay definition. It’s roughly: “if it doesn’t build and behave the same on a stable point release, file a bug, it

I don’t think there is any confusion around the lay definition. It’s roughly: “if it doesn’t build and behave the same on a stable point release, file a bug, it’s broken”. It’s ok to break point releases, particularly when there is a clear policy on the upper bound of such breakage. I’m not critical of the policy per se, it’s a eminently plausible experiment in PLT versioning. It’s pros and cons are somewhat understood now, and in 10 or 20 years when there are billions upon countless billions of lines of Rust code in production (which there will be) it will be totally obvious how it panned out. Just say “we break stable point releases in a subset of cases”. It’s ok. The thing that’s not ok, that I am critical of, is the seemingly boundless appetite of the Rust community to communicate in such a way that Rust is never wrong, or slower, or broken, or anything short of optimal. The optics are just wildly counter-productive here. You can go to practically other language community and hear “yeah, that was a mistake in retrospect”, or “yeah, sorry about that, we’re working on it”, or “yeah, language Y is probably a better fit for your needs”. 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”. This is not an isolated thing. It’s not the only example of that vibe. This weekend! It’s the default. And it’s not a good look. Edit to reply to (unannotated) edit: You’ve got the wrong commenter with part of the new paragraph, I didn’t say it happens routinely or anything like that. You do have the guy who fixes his own Rust issues rather than going to the community for what I imagine are by now obvious reasons.

hojjat12000 4y ago
> Rust community to communicate in such a way that Rust is never wrong Just read about Async Rust to see how critical of Rust the Rust community can be!
- benreesman 4y ago
  Haha fair play, async does seem to have been a bit of a journey: but it also seems to be shaping up nicely, and Rust is in good company vis-a-vis the every other programming language that has struggled to find a good story here. I’m case there is any confusion about whether or not I value Rust: literally my current work pertains to designing a DSL and compiler for async state machines (not totally unlike MSR’s P Language) because I need a way to compose extremely complicated async programs with hard correctness and performance properties. And while the implementation language is Haskell and the first target language is C++ because this is for $DAYJOB and I need C++ first, I have also gone to great pains to avoid anything that will stop the next target language from being Rust: it will soon generate idiomatic Rust code that ties into Rust’s Async story because I really like Rust’s Async story and I think/hope that Rust will be my primary low-cost abstraction language ASAP.
burntsushi 4y ago
> 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.

hojjat12000 4y ago

> Rust community to communicate in such a way that Rust is never wrong Just read about Async Rust to see how critical of Rust the Rust community can be!

benreesman 4y ago
Haha fair play, async does seem to have been a bit of a journey: but it also seems to be shaping up nicely, and Rust is in good company vis-a-vis the every other programming language that has struggled to find a good story here. I’m case there is any confusion about whether or not I value Rust: literally my current work pertains to designing a DSL and compiler for async state machines (not totally unlike MSR’s P Language) because I need a way to compose extremely complicated async programs with hard correctness and performance properties. And while the implementation language is Haskell and the first target language is C++ because this is for $DAYJOB and I need C++ first, I have also gone to great pains to avoid anything that will stop the next target language from being Rust: it will soon generate idiomatic Rust code that ties into Rust’s Async story because I really like Rust’s Async story and I think/hope that Rust will be my primary low-cost abstraction language ASAP.

burntsushi 4y ago

> 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.