Warning: Some posts on this platform may contain adult material intended for mature audiences only. Viewer discretion is advised. By clicking ‘Continue’, you confirm that you are 18 years or older and consent to viewing explicit content.
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.
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.
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.
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.
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.
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.