

Establishing the Rust-Python FFI - wafflespeanut
http://wafflespeanut.github.io/blog/2015/07/08/a-pythonist-getting-rusty-these-days-dot-dot-dot-part-2/

======
adwhit
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.

------
megaman821
Maybe it is just me, but whenever I come across a type as ugly as * const *
const c_char I would create a type alias. That way I can remember what it is a
month later. Would this work in Rust?

    
    
        type c_str = *const c_char
        type c_str_arr = *const c_str
    
        pub extern fn get_stuff(array: c_str_arr, length: size_t) -> c_str {...}

~~~
FreeFull
Yes, that exact code would work, except with some extra semicolons.

