5 ms·

> - Not require keeping a litany of compiler versions around just to keep older code building. Do you have a single example of this? We keep very close tabs on

> - Not require keeping a litany of compiler versions around just to keep older code building. Do you have a single example of this? We keep very close tabs on breakage in the wild even, and especially, for changes we were allowed to make (unlike say GCC, which happily breaks code if the language standard says the code never should have compiled in the first place). There are times when we've refused to make changes that we were allowed to make (because they were changes to unspecified behavior, which C/C++ has more of than Rust, and which GCC/Clang changes all the time) out of concern for breaking existing code. As far as I'm concerned, honestly, this is just FUD.

teacup50 10y ago
Your own release notes contain descriptions of breaking language changes. That may change as the language matures -- great. I keep an eye on Rust so that I can eventually try actually using it for kernel-level development work.
- steveklabnik 10y ago
  Again, so do C compilers, so does Java, so does every language, even ones that "never break". C11 removed gets, for example.
  - teacup50 10y ago
    javac, gcc, and clang all support some form of -std=<lang_level>, and ABI/source interop between code that uses different language versions. The post-gcc 2.95 C++ ABI breakage was pretty suck, though. [edit] And please don't misinterpret my criticism as intentional FUD. I work on $MAJOR_OS and am achingly tired of writing C, so I keep my eye on Rust as one possible salvation, once it's had time to mature. It's just a very hard sell when there's no ABI stability, we're talking about code that's expected to last for decades, etc.
    - steveklabnik 10y ago
      It's all good. I hear you. We'll get there :) It took C what, 17 years or something to have ABI stability?
- pcwalton 10y ago
  As I explained, those are only "breaking changes" in the sense that some code might break in practice, not that we changed the language definition. GCC did not provide a switch to get the old copy constructor behavior back when they made it stricter and broke my code.

teacup50 10y ago

Your own release notes contain descriptions of breaking language changes. That may change as the language matures -- great. I keep an eye on Rust so that I can eventually try actually using it for kernel-level development work.

steveklabnik 10y ago
Again, so do C compilers, so does Java, so does every language, even ones that "never break". C11 removed gets, for example.
- teacup50 10y ago
  javac, gcc, and clang all support some form of -std=<lang_level>, and ABI/source interop between code that uses different language versions. The post-gcc 2.95 C++ ABI breakage was pretty suck, though. [edit] And please don't misinterpret my criticism as intentional FUD. I work on $MAJOR_OS and am achingly tired of writing C, so I keep my eye on Rust as one possible salvation, once it's had time to mature. It's just a very hard sell when there's no ABI stability, we're talking about code that's expected to last for decades, etc.
  - steveklabnik 10y ago
    It's all good. I hear you. We'll get there :) It took C what, 17 years or something to have ABI stability?
pcwalton 10y ago
As I explained, those are only "breaking changes" in the sense that some code might break in practice, not that we changed the language definition. GCC did not provide a switch to get the old copy constructor behavior back when they made it stricter and broke my code.