this post was submitted on 25 Sep 2024
377 points (92.9% liked)
Programmer Humor
19310 readers
2220 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
What is this abi and standard calling methods you speak off? Are you a rust-non-believer or some shit! Rewrite it all in rust, no questions asked!
( i too like the ideas of rust, but without a decent abi or not constantly changing interface, its useless to me. I dont want to rebuild all code, including libraries every time i update 1 library in my application )
You're aware that Rust gives you access to the full C ABI?
What language are you going to use instead that has a better ABI story? Swift? Or maybe a dynamic language like Python?
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.