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.

[–] [email protected] 4 points 2 months ago* (last edited 1 month ago) (1 children)

Hmm. So I guess it comes down to what OP is doing. They either want to write a Rust library, or something that uses a Rust library that may not be standardised or even exist yet. If the latter, they should stick with C.

[–] [email protected] 3 points 2 months ago

Writing C bindings to a Rust library is the easier scenario because you can rely on the safe code having nice and clean memory semantics.

[–] [email protected] 2 points 2 months ago

Yeah, Rust has pretty good integration of it: https://doc.rust-lang.org/nomicon/ffi.html#calling-rust-code-from-c

You do lose some of the Rust-y-ness, because obviously the C ABI is much more simplistic, but in terms of a stable ABI, it's impossible to beat C.