8 ms·

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

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.
        rustdebatetime 11mo ago
        > 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 almost no practical stability nor good cross-compatibility in compilers. If the compiler optimization is compliant with the standard, then it is not a compiler bug. rustc developers have the same expectation when Rust developers mess up using unsafe, though the rules might be less defined for Rust than for C and C++, worsening the issue for Rust. I don't know where you got the idea that "almost no C programs [are] without UB". Did you get it from personal experience working with C and you having trouble avoiding UB? Unless you have a clear and reliable statistical source or other good source or argument for your claim, I encourage you to rescind that claim. C++ should in some cases be easier to avoid UB with than C. > > Rust is worse when unsafe is involved. > It's really not. It definitely, very much is. As just some examples among many, consider aliasing and pinning https://lwn.net/Articles/1030517/ https://lwn.net/Articles/1030517/ .
        Avamander 11mo ago
        > I don't know where you got the idea that "almost no C programs [are] without UB". Did you get it from personal experience working with C and you having trouble avoiding UB? Unless you have a clear and reliable statistical source or other good source or argument for your claim, I encourage you to rescind that claim. C++ should in some cases be easier to avoid UB with than C. From the fact that a lot of compilers can and do rely on UB to do certain optimizations. If UB wasn't widespread, they wouldn't have those optimization passes. You not knowing how widespread UB is in C and C++ codebases is very telling. You're however absolutely free to find me one large project that will not trigger "-fsanitizer=undefined" for starters. (Generated codebases do not count though.) > It definitely, very much is. As just some examples among many, consider aliasing and pinning https://lwn.net/Articles/1030517/ https://lwn.net/Articles/1030517/ . Difficult to understand or being unsafe does not make unsafe Rust worse than C. It's an absurd claim.

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.
      - rustdebatetime 11mo ago
        > 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 almost no practical stability nor good cross-compatibility in compilers. If the compiler optimization is compliant with the standard, then it is not a compiler bug. rustc developers have the same expectation when Rust developers mess up using unsafe, though the rules might be less defined for Rust than for C and C++, worsening the issue for Rust. I don't know where you got the idea that "almost no C programs [are] without UB". Did you get it from personal experience working with C and you having trouble avoiding UB? Unless you have a clear and reliable statistical source or other good source or argument for your claim, I encourage you to rescind that claim. C++ should in some cases be easier to avoid UB with than C. > > Rust is worse when unsafe is involved. > It's really not. It definitely, very much is. As just some examples among many, consider aliasing and pinning https://lwn.net/Articles/1030517/ https://lwn.net/Articles/1030517/ .
        Avamander 11mo ago
        > I don't know where you got the idea that "almost no C programs [are] without UB". Did you get it from personal experience working with C and you having trouble avoiding UB? Unless you have a clear and reliable statistical source or other good source or argument for your claim, I encourage you to rescind that claim. C++ should in some cases be easier to avoid UB with than C. From the fact that a lot of compilers can and do rely on UB to do certain optimizations. If UB wasn't widespread, they wouldn't have those optimization passes. You not knowing how widespread UB is in C and C++ codebases is very telling. You're however absolutely free to find me one large project that will not trigger "-fsanitizer=undefined" for starters. (Generated codebases do not count though.) > It definitely, very much is. As just some examples among many, consider aliasing and pinning https://lwn.net/Articles/1030517/ https://lwn.net/Articles/1030517/ . Difficult to understand or being unsafe does not make unsafe Rust worse than C. It's an absurd claim.