5 ms·

A little more than a year ago, breakage. https://devclass.com/2024/08/19/rust-1-80-0-breaks-existing-code-such-as-time-crate-exposes-compatibility-snag-with-ty

A little more than a year ago, breakage. https://devclass.com/2024/08/19/rust-1-80-0-breaks-existing-code-such-as-time-crate-exposes-compatibility-snag-with-type-inference https://devclass.com/2024/08/19/rust-1-80-0-breaks-existing-...

Avamander 11mo ago
Have you EVER used GCC? I wish each release only had bugs with inferring the type of auto or something.
- rustdebacletime 11mo ago
  And rustc uses LLVM, and has had several bugs as well, whether related to LLVM or just due to itself. But what I linked was intentional breakage, and it caused some people a lot of pain.
  - Avamander 11mo ago
    Yea, I can think of a lot of intentional GCC breakages as well. Especially ones related to optimizations. If we wrote an article for every one you'd never hear the end of it. So what's actually your point here?
    - rustdebacletime 11mo ago
      > Especially ones related to optimizations. Did they change the language? GCC is not meant to change the C or C++ languages (unless the user uses some flag to modify the language), there is an ISO standard that they seek to be compliant with. rustc, on the other hand, only somewhat recently got a specification or something from Ferrocene, and that specification looks lackluster and incomplete from when I last skimmed through it. And rustc does not seem to be developed against the official Rust specification.
      - Avamander 11mo ago
        > Did they change the language? That's not what you asked though, these were intentional breakages. Language standard or not. In any case though, bringing up language specification as an example for maturity is such a massive cop-out considering the amount of UB in C and C++. It's not like it gives you good stability or consistency. > there is an ISO standard that they seek to be compliant with You can buy RM 8048 from NIST, is that the "culture" of stability you have in mind?
        rustdebacletime 11mo ago
        > That's not what you asked though, these were intentional breakages. Language standard or not. You are completely wrong, and you ought to be able to see that already. It makes a world of difference if it is a language change or not. As shown in dtolnay's comment https://github.com/rust-lang/rust/issues/127343#issuecomment-2218261296 https://github.com/rust-lang/rust/issues/127343#issuecomment... . If breakage is not due to a language change, and the program is fully compliant with the standard, and there is no issue in the standard, then the compiler has a bug and must fix that bug. If breakage is due to a language change, then even if a program is fully compliant with the previous language version, and the programmer did nothing wrong, then the program is still the one that has a bug. In many language communities, language changes are therefore handled with care and changing the language version is generally set up to be a deliberate action, at least if there would be breakage in backwards compatibility. I do not see how it would be possible for you not to know that I am completely right about this and that you are completely wrong. For there is absolutely no doubt that that is the case. > In any case though, bringing up language specification as an example for maturity is such a massive cop-out considering the amount of UB in C and C++. Rust is worse when unsafe is involved. https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/ https://materialize.com/blog/rust-concurrency-bug-unbounded-...
        Avamander 11mo ago
        > If breakage is not due to a language change, and the program is fully compliant with the standard, and there is no issue in the standard, then the compiler has a bug and must fix that bug. There are almost no C programs without UB. So a lot of what you would call "compiler bugs" are entirely permitted standard. If you say "no true C program has UB" then of course, congrats, your argument might be in some aspects correct. But that's not really the case in practice and your language standard provides shit in terms of practical stability and cross-compatibility in compilers. > I do not see how it would be possible for you not to know that I am completely right about this and that you are completely wrong. For there is absolutely no doubt that that is the case. Lol, lmao even. > Rust is worse when unsafe is involved. It's really not.

Avamander 11mo ago

Have you EVER used GCC? I wish each release only had bugs with inferring the type of auto or something.

rustdebacletime 11mo ago
And rustc uses LLVM, and has had several bugs as well, whether related to LLVM or just due to itself. But what I linked was intentional breakage, and it caused some people a lot of pain.
- Avamander 11mo ago
  Yea, I can think of a lot of intentional GCC breakages as well. Especially ones related to optimizations. If we wrote an article for every one you'd never hear the end of it. So what's actually your point here?
  - rustdebacletime 11mo ago
    > Especially ones related to optimizations. Did they change the language? GCC is not meant to change the C or C++ languages (unless the user uses some flag to modify the language), there is an ISO standard that they seek to be compliant with. rustc, on the other hand, only somewhat recently got a specification or something from Ferrocene, and that specification looks lackluster and incomplete from when I last skimmed through it. And rustc does not seem to be developed against the official Rust specification.
    - Avamander 11mo ago
      > Did they change the language? That's not what you asked though, these were intentional breakages. Language standard or not. In any case though, bringing up language specification as an example for maturity is such a massive cop-out considering the amount of UB in C and C++. It's not like it gives you good stability or consistency. > there is an ISO standard that they seek to be compliant with You can buy RM 8048 from NIST, is that the "culture" of stability you have in mind?
      - rustdebacletime 11mo ago
        > That's not what you asked though, these were intentional breakages. Language standard or not. You are completely wrong, and you ought to be able to see that already. It makes a world of difference if it is a language change or not. As shown in dtolnay's comment https://github.com/rust-lang/rust/issues/127343#issuecomment-2218261296 https://github.com/rust-lang/rust/issues/127343#issuecomment... . If breakage is not due to a language change, and the program is fully compliant with the standard, and there is no issue in the standard, then the compiler has a bug and must fix that bug. If breakage is due to a language change, then even if a program is fully compliant with the previous language version, and the programmer did nothing wrong, then the program is still the one that has a bug. In many language communities, language changes are therefore handled with care and changing the language version is generally set up to be a deliberate action, at least if there would be breakage in backwards compatibility. I do not see how it would be possible for you not to know that I am completely right about this and that you are completely wrong. For there is absolutely no doubt that that is the case. > In any case though, bringing up language specification as an example for maturity is such a massive cop-out considering the amount of UB in C and C++. Rust is worse when unsafe is involved. https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/ https://materialize.com/blog/rust-concurrency-bug-unbounded-...
        Avamander 11mo ago
        > If breakage is not due to a language change, and the program is fully compliant with the standard, and there is no issue in the standard, then the compiler has a bug and must fix that bug. There are almost no C programs without UB. So a lot of what you would call "compiler bugs" are entirely permitted standard. If you say "no true C program has UB" then of course, congrats, your argument might be in some aspects correct. But that's not really the case in practice and your language standard provides shit in terms of practical stability and cross-compatibility in compilers. > I do not see how it would be possible for you not to know that I am completely right about this and that you are completely wrong. For there is absolutely no doubt that that is the case. Lol, lmao even. > Rust is worse when unsafe is involved. It's really not.