The Rustinomicon has a chapter on it. The basics are quite simple: Declare non-opaque types to use layout matching the C ABI, export/import functions, some wibbles around name mangling. Option<T> vs. null pointers. Where things get a bit more involved is unwinding, but then you’re at the end of it, nothing should be shocking to anyone having written C.
As to how Rusty it is… not very. I mean Rust has first-class FFI support, but the way FFI stuff is written is necessarily unidiomatic because you’re basically writing C in Rust syntax and you won’t get out of declaring your own functions `unsafe’ before you read the rest of the Rustinomicon to understand what properties you need to ensure because the nice and shiny parts of Rust assume them.
Are you suggesting OP write a C application and then compile it as Rust? I’m not a pro, but that sounds kind of janky.
I’m suggesting building a Rust library and exposing a C ABI. That’s what rsvg does for example.
Oh. There’s a still Rust-y way to do this? Nevermind.
OP wanted stability and predictability. I suppose we’ll see how entrenched one library can become.
The Rustinomicon has a chapter on it. The basics are quite simple: Declare non-opaque types to use layout matching the C ABI, export/import functions, some wibbles around name mangling.
Option<T>vs. null pointers. Where things get a bit more involved is unwinding, but then you’re at the end of it, nothing should be shocking to anyone having written C.As to how Rusty it is… not very. I mean Rust has first-class FFI support, but the way FFI stuff is written is necessarily unidiomatic because you’re basically writing C in Rust syntax and you won’t get out of declaring your own functions `unsafe’ before you read the rest of the Rustinomicon to understand what properties you need to ensure because the nice and shiny parts of Rust assume them.