8 ms·

Would this allow Rust libraries to be dynamically linked like C libraries are often?

by pabs3 4y ago

masklinn 4y ago
> The interoperable ABI does not aim to support the full richness of Rust's type system, or that of other languages. It aims to support common cases more safely and simply. So not much (or any) more than it currently is: it's not a stable Rust ABI, it's instead a more expressive ABI compared to C.
- kibwen 4y ago
  That said, even though it won't be "a stable Rust ABI", it will (if the experiment succeeds) be a stable ABI that is more Rust-like than the current C ABI.
JoshTriplett 4y ago
Yes, to some degree. You can dynamically link Rust today using the C ABI, but then you lose all the richness and safety of Rust types. The interoperable ABI will allow more of Rust's type system to work across the boundary.
flohofwoe 4y ago
As far as I understand the proposal, it's "just" standardizing how some high level Rust types would be automatically translated into a "C ABI" compatible representation, sort of like a builtin bindings generator. But I wonder why DLL linkage wouldn't already be possible without this proposal. C++ doesn't have a standardized ABI either, but it's possible to load shared libraries with C++ interfaces just fine - as long as they've been created with the same compiler and compiler version. Since there's only a single Rust compiler vendor I'd imagine that dynamic linkage should already be much less trouble than in C++ land?
- lmm 4y ago
  Rust moves much faster than C++, at least at the moment. So the practical benefit of sharing libraries created with the same compiler version would be much smaller.
- leni536 4y ago
  C++ absolutely has standardised ABIs, like the Itanium C++ ABI implemented by clang and gcc. The situation is not any better or worse than for C.
  - pjmlp 4y ago
    And on Windows, COM and WinRT, although they are language agnostic.
- Rusky 4y ago
  DLL linkage with the same compiler has been possible since the beginning- for instance rustc itself is built this way. This is about going beyond that so people can interop with other languages, link with DLLs without rebuilding them every 6 weeks, etc
matheusmoreira 4y ago
If it's a simple enough binary interface, sure. Simplicity is really important. C++ has standardized ABIs but you just don't see people dynamically loading a C++ shared object, obtaining a pointer to a C++ object and calling its member functions. They always do it through the C ABI if they do it at all. Some would rather rewrite stuff in C than put up with that. C++ ABIs are so obnoxiously complex the only things that dare to touch it are C++ compilers and even they have been known to break things. I just get this incredibly hopeless feeling whenever I try to contemplate how I'd handle a C++ exception from Python code. The only reasonable answer I can think of is I wouldn't, I'd just disable C++ exceptions instead and hope for the best. People use C because it's just simple symbols and unchanging calling conventions. Look up symbols to get function pointers, put parameters in specific registers, call the function and off you go. Nobody will interface with Rust if the ABI is too complex. Given the language's many high level abstractions, I think it's likely we'll see a repeat of the C++ situation above.
- AshamedCaptain 4y ago
  > C++ has standardized ABIs but you just don't see people dynamically loading a C++ shared object, obtaining a pointer to a C++ object and calling its member functions. They always do it through the C ABI if they do it at all. That does not match my experience at all. From the top of my head, Qt (QtPlugin) does C++ ABI plugins, and they do that almost transparently in a myriad of platforms. > I just get this incredibly hopeless feeling whenever I try to contemplate how I'd handle a C++ exception from Python code. At one point I could even catch C++ exceptions from Java, and viceversa (see gcj).
  - matheusmoreira 4y ago
    > From the top of my head, Qt (QtPlugin) does C++ ABI plugins This? https://wiki.qt.io/Plugins https://wiki.qt.io/Plugins > provides a bunch of macros that helps us create the C-function that generates the plugin object Looks like it uses the C ABI. > At one point I could even catch C++ exceptions from Java, and viceversa (see gcj). I'm interested in the details of that. Perhaps the GCJ compiler generated some sort of bridge between the languages?

Would this allow Rust libraries to be dynamically linked like C libraries are often?

by pabs3 4y ago

Would this allow Rust libraries to be dynamically linked like C libraries are often?

> The interoperable ABI does not aim to support the full richness of Rust's type system, or that of other languages. It aims to support common cases more safely and simply. So not much (or any) more than it currently is: it's not a stable Rust ABI, it's instead a more expressive ABI compared to C.

kibwen 4y ago
That said, even though it won't be "a stable Rust ABI", it will (if the experiment succeeds) be a stable ABI that is more Rust-like than the current C ABI.

JoshTriplett 4y ago

Yes, to some degree. You can dynamically link Rust today using the C ABI, but then you lose all the richness and safety of Rust types. The interoperable ABI will allow more of Rust's type system to work across the boundary.

flohofwoe 4y ago

As far as I understand the proposal, it's "just" standardizing how some high level Rust types would be automatically translated into a "C ABI" compatible representation, sort of like a builtin bindings generator. But I wonder why DLL linkage wouldn't already be possible without this proposal. C++ doesn't have a standardized ABI either, but it's possible to load shared libraries with C++ interfaces just fine - as long as they've been created with the same compiler and compiler version. Since there's only a single Rust compiler vendor I'd imagine that dynamic linkage should already be much less trouble than in C++ land?

lmm 4y ago
Rust moves much faster than C++, at least at the moment. So the practical benefit of sharing libraries created with the same compiler version would be much smaller.
leni536 4y ago
C++ absolutely has standardised ABIs, like the Itanium C++ ABI implemented by clang and gcc. The situation is not any better or worse than for C.
- pjmlp 4y ago
  And on Windows, COM and WinRT, although they are language agnostic.
Rusky 4y ago
DLL linkage with the same compiler has been possible since the beginning- for instance rustc itself is built this way. This is about going beyond that so people can interop with other languages, link with DLLs without rebuilding them every 6 weeks, etc

matheusmoreira 4y ago

If it's a simple enough binary interface, sure. Simplicity is really important. C++ has standardized ABIs but you just don't see people dynamically loading a C++ shared object, obtaining a pointer to a C++ object and calling its member functions. They always do it through the C ABI if they do it at all. Some would rather rewrite stuff in C than put up with that. C++ ABIs are so obnoxiously complex the only things that dare to touch it are C++ compilers and even they have been known to break things. I just get this incredibly hopeless feeling whenever I try to contemplate how I'd handle a C++ exception from Python code. The only reasonable answer I can think of is I wouldn't, I'd just disable C++ exceptions instead and hope for the best. People use C because it's just simple symbols and unchanging calling conventions. Look up symbols to get function pointers, put parameters in specific registers, call the function and off you go. Nobody will interface with Rust if the ABI is too complex. Given the language's many high level abstractions, I think it's likely we'll see a repeat of the C++ situation above.

AshamedCaptain 4y ago
> C++ has standardized ABIs but you just don't see people dynamically loading a C++ shared object, obtaining a pointer to a C++ object and calling its member functions. They always do it through the C ABI if they do it at all. That does not match my experience at all. From the top of my head, Qt (QtPlugin) does C++ ABI plugins, and they do that almost transparently in a myriad of platforms. > I just get this incredibly hopeless feeling whenever I try to contemplate how I'd handle a C++ exception from Python code. At one point I could even catch C++ exceptions from Java, and viceversa (see gcj).
- matheusmoreira 4y ago
  > From the top of my head, Qt (QtPlugin) does C++ ABI plugins This? https://wiki.qt.io/Plugins https://wiki.qt.io/Plugins > provides a bunch of macros that helps us create the C-function that generates the plugin object Looks like it uses the C ABI. > At one point I could even catch C++ exceptions from Java, and viceversa (see gcj). I'm interested in the details of that. Perhaps the GCJ compiler generated some sort of bridge between the languages?