6 ms·

Your post strongly reinforces Rust's reputation as a language whose language designers are willing to break compatibility on a whim. If Rust proponents argue li

Your post strongly reinforces Rust's reputation as a language whose language designers are willing to break compatibility on a whim. If Rust proponents argue like this, what breakage will not be forced upon Rust users in the future? Your post itself reinforces the OP's claim. Edit: Seriously. At this point, it seems clear that the culture around Rust, especially driven by proponents like you, indirectly have a negative effect on both Rust software, and software security & quality overall, as seen by the bug discussed in the OP. Without your kind of post, would Ubuntu have felt less pressured to make technical management decisions that allowed for the above bug?

aw1621107 11mo ago
> Your post strongly reinforces Rust's reputation as a language whose language designers are willing to break compatibility on a whim. > Your post itself reinforces the OP's claim. Again, I think it might be worth elaborating precisely what you think "on a whim" means. To me (and I would hope anyone else with a reasonable command of English), making a bad decision is not the same thing as making a decision on a whim, and you have provided no reason to believe the described change falls under the latter category instead of the former.
- rustdebacletime 11mo ago
  This new post you have made again reinforces the general notion that, yes, closer to "on a whim" than many like, the Rust community is willing to break backwards compatibility. It reflects extremely poorly on the Rust community in some people's eyes that you and other proponents appear to not only be unwilling to admit the issues, like the above issue that caused some people a lot of pain, but even directly talk around the issues. In C and C++ land, if gcc (as a thought experiment) tried breaking backwards compatibility by changing the language, people would be flabbergasted, complain that gcc made a dialect, and switch to Clang or MSVC or fork gcc. But for Rust, Rust developers just have to suck it up if rustc breaks backwards compatibility. Like Dtolnay's comment in the Github issue I linked indicates. If and once gccrs gets running, that might change. Though I am beginning to worry, for the specification for Rust gotten from Ferrocene might be both incomplete and basically fake, and that might cause rustc and gccrs to more easily risk becoming separate dialects of Rust, which would be horrible for Rust, and since there should preferably be more viable options in my opinion of systems languages, arguably horrible for the software ecosystem as well. I hope that there are plans for robust ways of preventing dialects of Rust.
  - aw1621107 11mo ago
    > yes, closer to "on a whim" than many like You're moving the goalposts. Neither the original claim nor your previous comment in this subthread used such vague and weakening qualifiers to "on a whim". And even those still don't say anything about what exactly you mean by "on a whim" or how precisely that particular change can be described as such, though at this rate I suppose there's not much hope in actually getting an on-point answer. > the Rust community is willing to break backwards compatibility Again, the fact that Rust can and will break backwards compatibility is not in dispute. It's specifically the claim that it's done "on a whim" that was the seed of this subthread. > appear to not only be unwilling to admit the issues I suggest you read my comment more carefully. I also challenge you to find anyone who claims that the changes in Rust 1.80.0 did not cause problems. > but even directly talk around the issues. Because once again, the existence of breaking changes and/or their negative downstream impact is not what the original comment you replied to was disputing! I'm not sure why this is so hard to understand. > In C and C++ land, if gcc (as a thought experiment) tried breaking backwards compatibility by changing the language, people would be flabbergasted, complain that gcc made a dialect, and switch to Clang or MSVC or fork gcc. No need for a thought experiment. Straight from the GCC docs [0]: > By default, GCC provides some extensions to the C language that, on rare occasions conflict with the C standard. > The default, if no C language dialect options are given, is -std=gnu23. > By default, GCC also provides some additional extensions to the C++ language that on rare occasions conflict with the C++ standard. > The default, if no C++ language dialect options are given, is -std=gnu++17. Also from the GCC docs [1]: > The compiler can accept several base standards, such as ‘c90’ or ‘c++98’, and GNU dialects of those standards, such as ‘gnu90’ or ‘gnu++98’. So not only has GCC "chang[ed] the language" by implementing extensions that can conflict with the C/C++ standards, GCC has its own dialect and uses it by default. And yet there's no major GCC fork and no mass migration to Clang or MSVC specifically because of those extensions. And it's not like those extensions go unused either; perhaps the most well-known example is Linux, which only officially supported compilation via GCC for a long time precisely because Linux made (and makes!) extensive use of GCC extensions. It was only after a concerted effort to remove some of those GNU-isms and add support for others into Clang that mainline Clang could compile mainline Linux [2]. > I hope that there are plans for robust ways of preventing dialects of Rust. This is not a realistic option for any language that anyone is free to implement for what I hope are obvious reasons. [0]: https://gcc.gnu.org/onlinedocs/gcc/Standards.html https://gcc.gnu.org/onlinedocs/gcc/Standards.html [1]: https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html [2]: https://www.phoronix.com/review/clang-linux-53 https://www.phoronix.com/review/clang-linux-53

aw1621107 11mo ago

> Your post strongly reinforces Rust's reputation as a language whose language designers are willing to break compatibility on a whim. > Your post itself reinforces the OP's claim. Again, I think it might be worth elaborating precisely what you think "on a whim" means. To me (and I would hope anyone else with a reasonable command of English), making a bad decision is not the same thing as making a decision on a whim, and you have provided no reason to believe the described change falls under the latter category instead of the former.

rustdebacletime 11mo ago
This new post you have made again reinforces the general notion that, yes, closer to "on a whim" than many like, the Rust community is willing to break backwards compatibility. It reflects extremely poorly on the Rust community in some people's eyes that you and other proponents appear to not only be unwilling to admit the issues, like the above issue that caused some people a lot of pain, but even directly talk around the issues. In C and C++ land, if gcc (as a thought experiment) tried breaking backwards compatibility by changing the language, people would be flabbergasted, complain that gcc made a dialect, and switch to Clang or MSVC or fork gcc. But for Rust, Rust developers just have to suck it up if rustc breaks backwards compatibility. Like Dtolnay's comment in the Github issue I linked indicates. If and once gccrs gets running, that might change. Though I am beginning to worry, for the specification for Rust gotten from Ferrocene might be both incomplete and basically fake, and that might cause rustc and gccrs to more easily risk becoming separate dialects of Rust, which would be horrible for Rust, and since there should preferably be more viable options in my opinion of systems languages, arguably horrible for the software ecosystem as well. I hope that there are plans for robust ways of preventing dialects of Rust.
- aw1621107 11mo ago
  > yes, closer to "on a whim" than many like You're moving the goalposts. Neither the original claim nor your previous comment in this subthread used such vague and weakening qualifiers to "on a whim". And even those still don't say anything about what exactly you mean by "on a whim" or how precisely that particular change can be described as such, though at this rate I suppose there's not much hope in actually getting an on-point answer. > the Rust community is willing to break backwards compatibility Again, the fact that Rust can and will break backwards compatibility is not in dispute. It's specifically the claim that it's done "on a whim" that was the seed of this subthread. > appear to not only be unwilling to admit the issues I suggest you read my comment more carefully. I also challenge you to find anyone who claims that the changes in Rust 1.80.0 did not cause problems. > but even directly talk around the issues. Because once again, the existence of breaking changes and/or their negative downstream impact is not what the original comment you replied to was disputing! I'm not sure why this is so hard to understand. > In C and C++ land, if gcc (as a thought experiment) tried breaking backwards compatibility by changing the language, people would be flabbergasted, complain that gcc made a dialect, and switch to Clang or MSVC or fork gcc. No need for a thought experiment. Straight from the GCC docs [0]: > By default, GCC provides some extensions to the C language that, on rare occasions conflict with the C standard. > The default, if no C language dialect options are given, is -std=gnu23. > By default, GCC also provides some additional extensions to the C++ language that on rare occasions conflict with the C++ standard. > The default, if no C++ language dialect options are given, is -std=gnu++17. Also from the GCC docs [1]: > The compiler can accept several base standards, such as ‘c90’ or ‘c++98’, and GNU dialects of those standards, such as ‘gnu90’ or ‘gnu++98’. So not only has GCC "chang[ed] the language" by implementing extensions that can conflict with the C/C++ standards, GCC has its own dialect and uses it by default. And yet there's no major GCC fork and no mass migration to Clang or MSVC specifically because of those extensions. And it's not like those extensions go unused either; perhaps the most well-known example is Linux, which only officially supported compilation via GCC for a long time precisely because Linux made (and makes!) extensive use of GCC extensions. It was only after a concerted effort to remove some of those GNU-isms and add support for others into Clang that mainline Clang could compile mainline Linux [2]. > I hope that there are plans for robust ways of preventing dialects of Rust. This is not a realistic option for any language that anyone is free to implement for what I hope are obvious reasons. [0]: https://gcc.gnu.org/onlinedocs/gcc/Standards.html https://gcc.gnu.org/onlinedocs/gcc/Standards.html [1]: https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html [2]: https://www.phoronix.com/review/clang-linux-53 https://www.phoronix.com/review/clang-linux-53