6 ms·

If only compiler developers had this attitude.

• rkangel 9y ago
  I think Rust has done this quite well, managing to have the best of both worlds. Unstable features are only available on the nightly build and need specifically enabling (and their interface may change). Once a feature is considered stable it is carefully maintained. They do have some breaking changes, but they're not common and for unusual edge cases: https://killercup.github.io/bitrust/ https://killercup.github.io/bitrust/ This explains the Rust approach: https://blog.rust-lang.org/2014/10/30/Stability.html https://blog.rust-lang.org/2014/10/30/Stability.html
  • snuxoll 9y ago
    Rust also has yet to develop a stable ABI, I know they’re hard at work on so many things so I don’t say this as some snide remark - but until this is the case and Rust supports proper dynamic linking there’s whole domains of tasks I’m not comfortable using it for.
    • steveklabnik 9y ago
      I can assure you we’re not actively working on a stable ABI.
      • majewsky 9y ago
        This is a thing I've been wondering about. Is dynamic linking (in the way that C/C++ programs use it all the time) not a usecase that Rust wants to cover?
        • steveklabnik 9y ago
          You can do dynamic linking, you just can't do it across compiler versions. This is how all of the Linux distros are doing it, for example. It's a spectrum: Rust: recompile the world when you update the compiler C++: recompile the world when you change ABIs or when the ABI changes (My understanding is that MSVC++ changes the ABI every ~2 years? I could be wrong.) C: never recompile the world It's not that we don't want the benefits of a stable ABI, but it's a monumental task, and there are more important things for now. Don't forget that you can get a stable ABI today by using the C ABI. You just lose out on the fancier features Rust has.
          • Karliss 9y ago
            Starting with vs2015 microsoft promises more stable abi.
          • the_why_of_y 9y ago
            > C++: recompile the world when you change ABIs or when the ABI changes (My understanding is that MSVC++ changes the ABI every ~2 years? I could be wrong.) This is only half true: every new release, the ABI of the runtime library changes. But the Visual C++ compiler ABI hasn't changed in decades. If you design your own library ABIs so they don't pass std::foobars around, you can link C++ libraries built with VC++6 with ones built with the latest version, and the whole thing is going to work fine - the trick is that multiple versions of the runtime DLLs can coexist in the same process. GCC/libstdc++ hasn't changed its ABI in more than a decade, since release 3.3 or 3.4; they even did incompatible changes to std::string in GCC 5 without breaking ABI: https://developers.redhat.com/blog/2015/02/05/gcc5-and-the-c11-abi/ https://developers.redhat.com/blog/2015/02/05/gcc5-and-the-c...
            • steveklabnik 9y ago
              Great, thank you for the clarification.
      • snuxoll 9y ago
        Unfortunate, but expected. On that note, would there be any breakage loading multiple Rust .so's with differing compiler/stdlib versions into the same process? This is one of my main concerns about the lack of ABI stability and the static-linking-first design of Rust. With C++ at the very least I know Red Hat isn't going to break the ABI within a major release, but the Rust 1.21 packages are already in epel-testing.
        • steveklabnik 9y ago
          If you want to ensure that there's no breakage, the only way is to use the same version of the compiler on all the Rust code.
    • pcwalton 9y ago
      Well, Rust has a stable ABI in the same sense that C++ has a stable ABI: you get a stable ABI if you use an extern "C" and repr(C) layer at the linkage level, or you use the same version of the compiler to compile all your code. It's not ideal for some use cases (though I think not having a stable ABI is the right decision at this stage), but it's not worse than C++.
  • lmkg 9y ago
    Rust also uses a sizable fraction of all publicly-available Rust code as a regression suite for compiler updates. This allows them to check edge cases that are "breaking in theory" to find out if there's actually any code that would be broken, or if the edge case had literally not yet been encountered.
    • Cshelton 9y ago
      By sizable fraction, he is referring to Cargo.io, Rust's public package repository. They literally run all tests against every crate published to the package ecosystem. That is amazing.
      • majewsky 9y ago
        Makes you wonder why no-one else came up with that idea before. I mean, it is pretty revolutionary, but also really obvious in hindsight.
        • steveklabnik 9y ago
          http://cpantesters.org/ http://cpantesters.org/
        • taeric 9y ago
          I'm curious why this is seen as a new idea. The capability to pull it off is somewhat new. In particular, at such a large scale. But the idea is far from it. Commercial compilers probably had this more than open source ones in the past. Though, oddly, it was probably a weakness in some respects, since it almost certainly slowed feature development/releases.
      • sevagh 9y ago
        Crates.io
• emodendroket 9y ago
  Do they not? It certainly seems to be a guiding principle of C# compiler developers, who have almost always opted to preserve unintended quirks of the compiler/spec rather than "fix" them.
• maccard 9y ago
  gcc and clang are _fairly_ good for this, and even MSVC has been getting better.
• flamedoge 9y ago
  ... just recompile