Re: The Case for Rust (in the base system)

On Sun, Jan 21, 2024 at 09:04:52AM -0700, Alan Somers wrote:
> Wow, there have been a lot of responses.  I think I touched on a
> sensitive issue.  I'll group everything together in one reply.  TLDR;
> I think imp's proposal is best.
> 
> * Rust's ABI is too unstable to use for libraries
> 
> This actually isn't a problem.  The stability situation for the Rust ABI is
> similar to C++; you can't link a C++ app to a C++ library unless they were both
> built with the same compiler version.  The C ABI, of course, is quite stable.
> And it's very easy to build a Rust library as a cdylib so that C applications
> can access it.  But there are restrictions: the library's public API can't do
> things that C can't, like generic functions.
I do not think this paragraph is accurate.

First, there is C++ ABI, that is followed by compilers, and divergences are
treated as serious bugs.

Second, even if you limit Rust library to C-representable features,
it is still not guaranteed to have stable external ABI. You need to
apply a lot of FFI powder to the interface, starting with repr(C) for
types (otherwise layou is not stable) and functions name mangling
control (again no guarantee for the mangling scheme stability), ending
with proper types use and absence of definition what is C-compatible
interface.