Hacker News Reader

Comment by mlindner | Hacker News Reader

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

View on HN

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

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.

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.

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

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.

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.

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

Any difficulty on understanding your types and discovering their sizes will make it harder to use the ABI. Any convention that you decide not to follow will break the interoperability of other software you may call over the ABI. And the C ABI doesn't carry information about memory management because people decided to build it that way, it could very well do it.

But if you want to define an "ABI" as strictly the geometry the data has on the memory when a function is called... well, good luck using that information on the other end to retrieve the data on your function; it's completely useless. But yes, I don't see any problem on it either.

The C ABI carries memory ownership information just fine - you simply pass a struct with two pointers, one for the memory, one for the function that does the cleanup.

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.

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

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

EDIT: Added a link to the ABI doc.

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.

Reply on news.ycombinator.com