4 ms·

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 a

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++.

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++.