I have recently been writing a Rust FFI for (an obscure dynamic array-language) Q. Unlike the OP, I didn't do it for speedups - in fact my Rust code is no faster than native Q. However there are other reasons to write FFIs - to benefit from Rust's extremely powerful type system, which can all-but-guarantee a program's correctness.
For example I recently spent a fortnight trying to write a parser for a complex binary file format in Q, but the dynamic typing got in the way. I would constantly find that some invariant would get broken without my understanding how, and refactoring was a matter of "change this here, run until it breaks, then fix, repeat". Eventually I gave up and rewrote in Rust. It took the same amount of time but the implementation is rock solid and I am confident that it won't ever crash and that e.g. malformed data will be identified and handled correctly.
I am now getting into the habit of reaching for Rust whenever I get bogged down with another language - it makes everything else seem brittle and slow.
For example I recently spent a fortnight trying to write a parser for a complex binary file format in Q, but the dynamic typing got in the way. I would constantly find that some invariant would get broken without my understanding how, and refactoring was a matter of "change this here, run until it breaks, then fix, repeat". Eventually I gave up and rewrote in Rust. It took the same amount of time but the implementation is rock solid and I am confident that it won't ever crash and that e.g. malformed data will be identified and handled correctly.
I am now getting into the habit of reaching for Rust whenever I get bogged down with another language - it makes everything else seem brittle and slow.