6 ms·

Ok, so why not say: “Our core maintainers internally use a definition of ‘breaking change’ that is different than the commonly accepted definition as a useful,

Ok, so why not say: “Our core maintainers internally use a definition of ‘breaking change’ that is different than the commonly accepted definition as a useful, and we feel necessary, fiction. This is detailed in RFC such-and-such, along with our rationale for this somewhat surprising choice. The reality is that we do break working production code past 1.0, though we invest great effort in trying not to, and we believe the benefits of being able to occasionally break production code outweigh the costs in practice”. Linus doesn’t break userspace. Back when Raymond Chen’s clique at Microsoft ran the show, Windows would honor use-after-free in SimCity or whatever on a new kernel. They didn’t break working stuff. Python 3 took forever because they felt it necessary to tear out subtle but critical assumptions, e.g. around strings and UTF-8 and stuff. “We don’t break stuff.” is hard, it has serious costs to go along with it’s obvious benefits, and it’s not the only way. It’s fine if Rust is going a different way, and it might be a revolution in this is a better way, we’ll know in twenty short years! :) But trying to lawyer around it so that “Rust isn’t wrong, you’re wrong, just see Appendix F Subsection 42.6” when someone is staring at a broken build is not the Done Thing. It’s not particularly respectful to the people who bend over backwards to honor the common-law definition of “break”, and it’s a canonical example of what many hackers dislike about interactions with the Rust community. I feel very strongly there is a more productive path here.

steveklabnik 4y ago
While maintainers may use a very technical sense of breaking change, that doesn’t mean in the end it doesn’t correspond to a lay usage of the term. The “ "Upgrading to a new stable compiler version requires either no changes or extremely small and easy changes to my code," question I posted below is what I would argue the lay understanding of the term means, and as the survey showed, it is extremely close to zero. That you believe that the team goes “uhhh actually sorry your code isn’t broken due to subsection 2.4.f” shows that you don’t actually engage with Rust in this respect. Can you cite the Rust team breaking a bunch of user code and then responding this way when the inevitable outcry comes? I can’t think of a single time that that’s happened, though I am of course fallible. Given that you claim it happens regularly it should be easy! Literally the comment that started this sub thread is about the Rust team not making a change that would break a reasonably popular tool because it would harm users.
- benreesman 4y ago
  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.

steveklabnik 4y ago

While maintainers may use a very technical sense of breaking change, that doesn’t mean in the end it doesn’t correspond to a lay usage of the term. The “ "Upgrading to a new stable compiler version requires either no changes or extremely small and easy changes to my code," question I posted below is what I would argue the lay understanding of the term means, and as the survey showed, it is extremely close to zero. That you believe that the team goes “uhhh actually sorry your code isn’t broken due to subsection 2.4.f” shows that you don’t actually engage with Rust in this respect. Can you cite the Rust team breaking a bunch of user code and then responding this way when the inevitable outcry comes? I can’t think of a single time that that’s happened, though I am of course fallible. Given that you claim it happens regularly it should be easy! Literally the comment that started this sub thread is about the Rust team not making a change that would break a reasonably popular tool because it would harm users.

benreesman 4y ago
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.