4 ms·

This is huge news!! I've been waiting for something like this from the Rust team for years! I hope libraries can be built for other languages that would allow c

This is huge news!! I've been waiting for something like this from the Rust team for years! I hope libraries can be built for other languages that would allow cleaner interfacing directly with Rust that doesn't rely on the boat anchor of the legacy C ABI that all languages are tied to! This is the most important "feature" of Rust for it's long term success. Edit: It looks like this is still using C ABI as it's base, which increases the burden for other languages to implement it. What a let down...

generichuman 4y ago
> It looks like this is still using C ABI as it's base, which increases the burden for other languages to implement it. What a let down... How so? It seems to me that actually decreases the burden. For example C# people may not implement the Rust ABI if they don't want to, but since they (and basically every language) already support C ABI, I can implement a library over the existing C ABI so that I can access Rust types.
- kibwen 4y ago
  Correct, the entire goal of defining it in terms of the C ABI is that C is the lingua franca that every language already speaks, so anything built on top of that has a dramatically lowered barrier to entry. I assume that the grandparent poster was thinking about making it possible for hypothetical future languages to someday be able to forego supporting the C ABI entirely, which is certainly a laudable goal (there's plenty of historical baggage there), but what the Rust developers care more about here is simply being able to do FFI that's safer than what currently exists.
- mlindner 4y ago
  Because if you're implementing it properly with the advanced features of a language such as Rust, you need to similarly create an entirely different ABI that goes down to the C ABI, increasing the complexity of the implementation because the C ABI has so many edge cases. Basing it on the C ABI makes it only easier for "simple" languages like C to communicate with Rust.
  - kibwen 4y ago
    > increasing the complexity of the implementation because the C ABI has so many edge cases. Every language speaks C, and whether we like it or not every new language will continue to speak C for the foreseeable (for-C-able?) future. This cost is already baked in, so you might as well leverage it to reduce the cost of a second ABI by building it on top of the ABI you're already guaranteed to support.
  - duped 4y ago
    What edge cases are there in the C ABI, and what can't you represent with it? The big problem to me is sharing pointers across FFI which is extremely dangerous in managed languages where the pointer could be invalidated by a GC sweep, but I don't think that's terribly relevant to Rust.
    - marcosdumay 4y ago
      They inherit a lot of issues from C like badly defined types; they imply on some unfit conventions like \0 terminated strings; they do have some issues defining the memory managing model (but I think that's unavoidable). I have never dwelled on low-level compatibility for long, so I certainly don't know about most issues. But even with a very small view, cleaning the leggacy looks like a very worthwhile thing to do. Maybe after Rust has gained more adoption, we can start to make C adhere to it, instead of the other way around.
      - duped 4y ago
        The C ABI is (broadly speaking) a standard way to layout structs and a choice of calling convention for the platform. That doesn't influence which types are/are-not defined (and the superset of a C compatible ABI can fix some subtle issues there, like untagged unions). Null terminated strings are not a part of the ABI, they're a convention in C libraries. Same goes for memory management, that's not really a part of the ABI (but it is an issue, since you need to define who is responsible for memory if it is shared across FFI, but again, the big issue there is garbage collection).
CoastalCoder 4y ago
Does "C ABI" mean the same thing as each platform's system ABI? E.g., on x86-64 Linux, the System V x86-64 ABI [0]? [0] https://www.owalle.com/2021/12/30/function-calling-sequence/abi.pdf https://www.owalle.com/2021/12/30/function-calling-sequence/... EDIT: Added a link to the ABI doc.
- flohofwoe 4y ago
  IMHO yes, if you squint a bit, there's no such thing as a "C ABI", C compilers just happen to implement those CPU/OS specific ABIs without much 'translation work' going on.
flohofwoe 4y ago
Well, you need some standard convention on how functions parameters and return values map to registers and memory locations. Whether those conventions are called "C ABI" or not doesn't really matter, those ABI conventions are much closer to the CPU architecture than any specific programming language anyway.
- flafla2 4y ago
  Indeed, it’s more accurate to say that C was designed around common asm calling conventions of its day, than the other way around.

generichuman 4y ago

> It looks like this is still using C ABI as it's base, which increases the burden for other languages to implement it. What a let down... How so? It seems to me that actually decreases the burden. For example C# people may not implement the Rust ABI if they don't want to, but since they (and basically every language) already support C ABI, I can implement a library over the existing C ABI so that I can access Rust types.

kibwen 4y ago
Correct, the entire goal of defining it in terms of the C ABI is that C is the lingua franca that every language already speaks, so anything built on top of that has a dramatically lowered barrier to entry. I assume that the grandparent poster was thinking about making it possible for hypothetical future languages to someday be able to forego supporting the C ABI entirely, which is certainly a laudable goal (there's plenty of historical baggage there), but what the Rust developers care more about here is simply being able to do FFI that's safer than what currently exists.
mlindner 4y ago
Because if you're implementing it properly with the advanced features of a language such as Rust, you need to similarly create an entirely different ABI that goes down to the C ABI, increasing the complexity of the implementation because the C ABI has so many edge cases. Basing it on the C ABI makes it only easier for "simple" languages like C to communicate with Rust.
- kibwen 4y ago
  > increasing the complexity of the implementation because the C ABI has so many edge cases. Every language speaks C, and whether we like it or not every new language will continue to speak C for the foreseeable (for-C-able?) future. This cost is already baked in, so you might as well leverage it to reduce the cost of a second ABI by building it on top of the ABI you're already guaranteed to support.
- duped 4y ago
  What edge cases are there in the C ABI, and what can't you represent with it? The big problem to me is sharing pointers across FFI which is extremely dangerous in managed languages where the pointer could be invalidated by a GC sweep, but I don't think that's terribly relevant to Rust.
  - marcosdumay 4y ago
    They inherit a lot of issues from C like badly defined types; they imply on some unfit conventions like \0 terminated strings; they do have some issues defining the memory managing model (but I think that's unavoidable). I have never dwelled on low-level compatibility for long, so I certainly don't know about most issues. But even with a very small view, cleaning the leggacy looks like a very worthwhile thing to do. Maybe after Rust has gained more adoption, we can start to make C adhere to it, instead of the other way around.
    - duped 4y ago
      The C ABI is (broadly speaking) a standard way to layout structs and a choice of calling convention for the platform. That doesn't influence which types are/are-not defined (and the superset of a C compatible ABI can fix some subtle issues there, like untagged unions). Null terminated strings are not a part of the ABI, they're a convention in C libraries. Same goes for memory management, that's not really a part of the ABI (but it is an issue, since you need to define who is responsible for memory if it is shared across FFI, but again, the big issue there is garbage collection).

CoastalCoder 4y ago

Does "C ABI" mean the same thing as each platform's system ABI? E.g., on x86-64 Linux, the System V x86-64 ABI [0]? [0] https://www.owalle.com/2021/12/30/function-calling-sequence/abi.pdf https://www.owalle.com/2021/12/30/function-calling-sequence/... EDIT: Added a link to the ABI doc.

flohofwoe 4y ago
IMHO yes, if you squint a bit, there's no such thing as a "C ABI", C compilers just happen to implement those CPU/OS specific ABIs without much 'translation work' going on.

flohofwoe 4y ago

Well, you need some standard convention on how functions parameters and return values map to registers and memory locations. Whether those conventions are called "C ABI" or not doesn't really matter, those ABI conventions are much closer to the CPU architecture than any specific programming language anyway.

flafla2 4y ago
Indeed, it’s more accurate to say that C was designed around common asm calling conventions of its day, than the other way around.