lobsters score: 4 · tags: plt, rust
This is very interesting, and I appreciate the move to replace C as the “universal FFI language”. It is a very bold choice and would require effort.
But a few things concern me, IMO the primary benefit of using the C ABI is that well, C is universal, and that you are not locked to a single compiler. It is true that rustc is the only practical Rust compiler right now, but that not might remain forever, and the current implementation of Valen would be difficult to port over to other Rust compilers.
Compilers needn’t be aware of what C toolchain they are using, or even have a C compiler at all on the system, and still communicate with other libraries on the C ABI.
Something like Swift might’ve been a better choice since it tackled this exact problem, it has a stable ABI, has an equally competent (if not more) type-system and also allows you to dynamically link. Of course, you would lose borrow checking and would have to use ARC, so I understand picking Rust instead.
score 1 · canonical
Compilers needn’t be aware of what C toolchain they are using, or even have a C compiler at all on the system, and still communicate with other libraries on the C ABI.
Unfortunately, that’s not really true. Give C Isn’t A Programming Language Anymore a read.
The TL;DR: IS that there is no “C ABI”. There isn’t even a single “C ABI” per platform… it’s a per-compiler thing, even on x86_64 Linux where everything tries to follow the Itanium ABI.
Yeah!
clang and gcc can’t even agree on the ABI of
__int128on x64 linux. That type is a gcc extension but it’s also explicitly defined and specified by the AMD64 SysV ABI in one of those nice human-readable PDFs!I wrote this dang thing to check for mistakes in rustc, I didn’t expect to find inconsistencies between the two major C compilers on one of the most important and well-trodden ABIs!
score 1 · canonical
There isn’t even a single “C ABI” per platform… it’s a per-compiler thing
Would you consider x86_64-pc-windows-msvc and x86_64-pc-windows-gnu to be one platform or two?
I don’t see a definition of “platform” in that post. One could regard the C compiler as being part of the platform’s identity, such that “per platform” vs “per-compiler” is not a distinction.
score 1 · canonical
I’d consider it to be one platform because “Windows” is what the overwhelming majority of people think of, whether or not they consciously understand the concept of a platform.
That’s why, outside of niche use-cases, it’s pretty fair to say that the platform is defined by the sentiment underlying “If it can’t feasibly run x86 Windows applications, it doesn’t qualify as Windows”. (I use “feasibly” to exclude last-resort-level emulation like qemu-user.)
We already have a term for incorporating the compiler (“target triple”) and incorporating the compiler into the concept of a platform just weakens the utility of “platform” and touches off the beginnings of the drift to coin a new word for the intuitive concept people intend to talk about… sort of like how, when most people talk about Linux, Android is excluded because they’re using it as a best-effort descriptor for the Linux+POSIX+X11/Wayland ABI that the “Linux” ecosystem is built around and, quite frankly, probably Linux+glibc+X11/Wayland.
(Hence why, for anyone not into tinkering with embedded hardware, “Linux” is pretty much defined by the phrase “If it can’t run my Linux-native Steam/GOG games, it’s not Linux” and ARM Linux is subject to the same forces as ARM Windows.)
When I target “Windows” as an application developer using Python or Godot or Unity or Electron or Visual Studio or countless other development systems, I don’t even need to know that MinGW exists unless it’s some niche thing like learning how to cross-compile Python extensions.
score 1 · canonical