5 ms·

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 backward

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
- rustdebacletime 11mo ago
  > You're moving the goalposts. Nope, I am not moving the goalposts, as is perfectly clear to you already. You are well aware that I am completely correct and that you are wrong. > 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. And you and the other Rust proponent's directly talking around it, as you again are doing here, only worsens the situation. > No need for a thought experiment. Straight from the GCC docs [0]: Technically correct, but outside of extensions that has to be enabled, more or less none of that breaks any backwards compatibility. A program written in pure C or C++ ought to behave exactly the same and compile exactly the same as in those default dialects. The default dialects amount to more or less just a strict superset that behaves the same, like adding support for C++ "//" comments, or backporting newer C standard changes to previous versions. The only extensions that change behavior significantly and are not only strict supersets with same behavior, require flags to be enabled. Thus, yet again, radically different from what the rustc developers did just last year. Overall, your posts and the posts of your fellow Rust proponents in this submission both worsen the situation for Rust and for software overall regarding compatibility, security and safety, as the bug of the submission indicates. Imagine being so brazen and doubling down on a path that arguably lead to a very public bug. I do not believe any responsible software company would want you anywhere near its code if it cared about safety and security.
  - aw1621107 11mo ago
    > Nope, I am not moving the goalposts, as is perfectly clear to you already. You are well aware that I am completely correct and that you are wrong. Turns out you have more than once. I wish I didn't have to spell this out for you, but here goes one last attempt... The original part of awesome_dude's comment that started this subthread: > Rust still has a very "Ready to make breaking changes on a whim" reputation Note the existence and wording of the qualifier here. The claim here is not "Ready to make breaking changes", but "Ready to make breaking changes on a whim". The relevant response from umanwizard: > What breaking changes has Rust made "on a whim"? Again, note the existence and wording of the qualifier. The question here is not "What breaking changes has Rust made", but "What breaking changes has Rust made 'on a whim' Your first response: > I don't know about "on a whim", but this isn't far off in regards to breaking compatibility. This is the first goalpost move. You're not claiming to have an example of a breaking change "on a whim" (in fact, you explicitly distance yourself from such a claim), but instead you say you have an example of a breaking change that "isn't far off" of being "on a whim". Note that this is not the same unadorned "on a whim" qualifier, as it uses the (slightly) weakening and more vague "isn't far off". How far off and in what way is it not far off? You fail to elaborate on both counts. Your next response: > Your post strongly reinforces Rust's reputation as a language whose language designers are willing to break compatibility on a whim. A second goalpost move. You're not using the "isn't far off" qualifier any more, and are instead using the unadorned "on a whim". Again, you fail to elaborate further on this. And finally: > closer to "on a whim" than many like A third goalpost move, with "on a whim" having grown two qualifiers, neither of which have previously appeared in this subthread! Now it's neither "on a whim" nor "isn't far off" "on a whim", but it's now "closer to" "on a whim" "than many like". How close is "closer to"? Who falls under "many"? How do these describe the example you provide? Who knows! > And you and the other Rust proponent's directly talking around it, as you again are doing here, only worsens the situation. It's not clear to me why it's so hard to understand what this subthread was originally about, nor why you seem so insistent on refusing to actually discuss the original topic. > Technically correct, but outside of extensions that has to be enabled, more or less none of that breaks any backwards compatibility. This is moving the goalposts yet again. We go from what is in effect "C/C++ compilers would never break backwards compatibility by adding language extensions!" to "You're correct in that they have done it, but it's mostly not a problem". > The default dialects amount to more or less just a strict superset that behaves the same, like adding support for C++ "//" comments, or backporting newer C standard changes to previous versions. The only extensions that change behavior significantly and are not only strict supersets with same behavior, require flags to be enabled. Not only does this claim contradict the snippets I quoted earlier, it also contradicts this other snippet from the docs (emphasis added) [0]: > On the other hand, when a GNU dialect of a standard is specified, all features supported by the compiler are enabled, even when those features change the meaning of the base standard. And given that GCC defaults to said GNU dialects, that means that non-strict-superset features are enabled by default. [0]: https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html

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

rustdebacletime 11mo ago
> You're moving the goalposts. Nope, I am not moving the goalposts, as is perfectly clear to you already. You are well aware that I am completely correct and that you are wrong. > 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. And you and the other Rust proponent's directly talking around it, as you again are doing here, only worsens the situation. > No need for a thought experiment. Straight from the GCC docs [0]: Technically correct, but outside of extensions that has to be enabled, more or less none of that breaks any backwards compatibility. A program written in pure C or C++ ought to behave exactly the same and compile exactly the same as in those default dialects. The default dialects amount to more or less just a strict superset that behaves the same, like adding support for C++ "//" comments, or backporting newer C standard changes to previous versions. The only extensions that change behavior significantly and are not only strict supersets with same behavior, require flags to be enabled. Thus, yet again, radically different from what the rustc developers did just last year. Overall, your posts and the posts of your fellow Rust proponents in this submission both worsen the situation for Rust and for software overall regarding compatibility, security and safety, as the bug of the submission indicates. Imagine being so brazen and doubling down on a path that arguably lead to a very public bug. I do not believe any responsible software company would want you anywhere near its code if it cared about safety and security.
- aw1621107 11mo ago
  > Nope, I am not moving the goalposts, as is perfectly clear to you already. You are well aware that I am completely correct and that you are wrong. Turns out you have more than once. I wish I didn't have to spell this out for you, but here goes one last attempt... The original part of awesome_dude's comment that started this subthread: > Rust still has a very "Ready to make breaking changes on a whim" reputation Note the existence and wording of the qualifier here. The claim here is not "Ready to make breaking changes", but "Ready to make breaking changes on a whim". The relevant response from umanwizard: > What breaking changes has Rust made "on a whim"? Again, note the existence and wording of the qualifier. The question here is not "What breaking changes has Rust made", but "What breaking changes has Rust made 'on a whim' Your first response: > I don't know about "on a whim", but this isn't far off in regards to breaking compatibility. This is the first goalpost move. You're not claiming to have an example of a breaking change "on a whim" (in fact, you explicitly distance yourself from such a claim), but instead you say you have an example of a breaking change that "isn't far off" of being "on a whim". Note that this is not the same unadorned "on a whim" qualifier, as it uses the (slightly) weakening and more vague "isn't far off". How far off and in what way is it not far off? You fail to elaborate on both counts. Your next response: > Your post strongly reinforces Rust's reputation as a language whose language designers are willing to break compatibility on a whim. A second goalpost move. You're not using the "isn't far off" qualifier any more, and are instead using the unadorned "on a whim". Again, you fail to elaborate further on this. And finally: > closer to "on a whim" than many like A third goalpost move, with "on a whim" having grown two qualifiers, neither of which have previously appeared in this subthread! Now it's neither "on a whim" nor "isn't far off" "on a whim", but it's now "closer to" "on a whim" "than many like". How close is "closer to"? Who falls under "many"? How do these describe the example you provide? Who knows! > And you and the other Rust proponent's directly talking around it, as you again are doing here, only worsens the situation. It's not clear to me why it's so hard to understand what this subthread was originally about, nor why you seem so insistent on refusing to actually discuss the original topic. > Technically correct, but outside of extensions that has to be enabled, more or less none of that breaks any backwards compatibility. This is moving the goalposts yet again. We go from what is in effect "C/C++ compilers would never break backwards compatibility by adding language extensions!" to "You're correct in that they have done it, but it's mostly not a problem". > The default dialects amount to more or less just a strict superset that behaves the same, like adding support for C++ "//" comments, or backporting newer C standard changes to previous versions. The only extensions that change behavior significantly and are not only strict supersets with same behavior, require flags to be enabled. Not only does this claim contradict the snippets I quoted earlier, it also contradicts this other snippet from the docs (emphasis added) [0]: > On the other hand, when a GNU dialect of a standard is specified, all features supported by the compiler are enabled, even when those features change the meaning of the base standard. And given that GCC defaults to said GNU dialects, that means that non-strict-superset features are enabled by default. [0]: https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html