Not unless you've slapped #[repr(C)] on the struct, else its layout may change.
#FFI-safety with Rust usage
pearl vault
radiant rock
From what I remember you really shouldn't because changing compiler versions (or similar small things) can totally break it when you load it
pearl vault
Even within the same compiler version, technically
Though in practice that wouldn't break
radiant rock
If you want to do a lot of Rust to rust ffi then you should probably look at using https://docs.rs/abi_stable/latest/abi_stable/
It does the extra work to make sure everything matches up when you load it
pearl vault
Few.
Unless it advertises it does, it generally doesn't.
Hot reloading is... Painful.
You have to basically pretend you're loading C code.
strong pelican
You've got two options for hot reloading Rust:
- setting up a C ABI for your crate and doing dynamic library loading / closing
- shove it into its own process and talk via RPC
radiant rock
Well... There is the wasm route 
pearl vault
It's Rust, yes, but unless you use abi_stable the simple issue of ABI stability locks you into writing stuff that would work with C.
strong pelican
Well, you'd pick some crate to do RPC with, like tonic (https://docs.rs/tonic/latest/tonic/index.html)
and set up some commands you can send to request the separate process shutdown so it can be started again
I'm not aware of any specific examples of this, outside of a project I haven't published the source for yet
Yeah.
Both ways are kinda painful, though not in identical ways
radiant rock
It's like what rust analyzer does
Where it's a separate process the editor talks to
strong pelican
Oh, one thing I'd like to note here: reloading dynamic libraries won't work with musl libc
(The "Unloading libraries" section)
Some notes, in no particular order:
- it is GPL licensed, so using it will impose some requirements you need to be aware of on distribution of your program
- it does seem convenient, however you would still need to handle making all types passed as arguments to these hotpatchable functions have a stable layout
- it appears to rely on the ABI of functions with no
externdeclaration, which is incorrect (I reviewed its code just now)
I like the idea, but this crate definitely needs more work that it doesn't appear to be getting
Hm, looks like it, yep