Hacker News Reader

Comment by fluffy87 | Hacker News Reader

Two issues with the post:

- An ABI is not a PL feature, but a platform feature, I.e., it is not that Rust does not have a stable ABI, but that eg Linux does not have a stable ABI for Rust (it has one for C and you can use this ABI from Rust).

- You can export generic Rust APIs with a stable C ABI by using trait objects, and it is often very easy to do this. So the claim that Rust and C++ are on the same boat wrt generics / instantiations is not true.

View on HN

> An ABI is not a PL feature, but a platform feature, I.e., it is not that Rust does not have a stable ABI, but that eg Linux does not have a stable ABI for Rust (it has one for C and you can use this ABI from Rust).

This is somewhat of a disingenuous thing to say, because it implies that the fault lies with linux for not providing a stable abi to rust. An ABI comprises various conventions wrt calling convention, name mangling, data layout, etc.; these are provided variably by the operating system, language specification, and language compiler. And, as TFA mentions, the rust compiler explicitly does not provide a stable ABI.

Windows does provide two cross language stable ABIs, CLR CLS and COM/UWP.

Mainframes also provide cross language stable ABIs, so called language environments.

I don’t agree.

The C ABI is specified in a spec that Linux adopts (eg the x86-psabi), and it is what allows all software using this abi (from assembly to C to Rust) to eg Interface with each other. Linux could write an ABI spec for Rust on its platform today and add a patch to the Rust compiler (or to a C++ comoiler) to adhere to this ABI.

Nobody has done this, and from many povs this is something that does not make much sense doing, but it’s up to the platform to specify how binary software communicates with each other. Linux only specifies this for C, and that’s what Rust software currently does and has to use on Linux.

In GNU/Linux it's the GNU part that supplies the C ABI. The GNU compiler collection provides it, and the GNU libc uses it talk with the Linux kernel, usually through traps appropriate to the CPU. The LLVM toolchain (and other alternatives, like ICC) conform to this de facto standard. The GNU devs designed their ABI long before Linux came along and it is mostly inherited from even older OSes like BSD and SVr4 and developed refined and adapted over decades by a common community of interests.

If you're going to criticise GNU/Linux for not providing a Rust ABI, make sure you're aiming at the GNU part. The Linux part doesn't care.

At the same time the C ABI is not part of the C standard. It's a GNU thing (or a Microsoft thing for Windows, or an Apple thing for Mac, or...). While they require the compiler to provide a stable ABI there's nothing preventing C20 (or future versions) from breaking existing C ABIs. It's not really right to talk about "the" C ABI, rather there's the x86 GCC ABI and the x86_64 GCC ABI and the x86 MSVC ABI and the MIPS GCC ABI and the...

That's why compilers have target "triples" (now more than 3 items): <CPU architecture><subarchitecture>-<vendor>-<os/system>-<abi>. So you might have ARMv7m-st-none-eabi for some embedded STM32 bare-metal code and x86_64-pc-linux-gnu for Linux. All C, all different ABIs.

> You can export generic Rust APIs with a stable C ABI by using trait objects, and it is often very easy to do this

do you have a guide for that ? all the reference I can find does not seem to behave any differently that it would in C++ - e.g. https://users.rust-lang.org/t/passing-a-trait-object-through... ; https://doc.rust-lang.org/nomicon/ffi.html ; ...

Reply on news.ycombinator.com