Great stuff!<p>One minor suggestion, completely beside the point so please forgive me: a safer and perhaps more idiomatic way to implement the multiply_safe function would be with a functional-style one-liner:<p><pre><code> fn multiply_safe(a : Vec<f64>, b : Vec<f64>) -> Vec<f64> {
if a.len() != b.len() {
panic!("The two vectors differ in length!");
}
return a.iter().zip(b.iter()).map(|(x, y)| x * y).collect()
}
</code></pre>
Safer because you don't manipulate indices and lengths directly like you would in C, so there is no opportunity of an off-by-one bug or things like that. Surprisingly, rustc optimizer makes sure that this performs as well as the index-wrangling implementation (according to some simple tests I just ran).
Well explained! Here are some more examples using the calllib function to access the rust code, although I think the mex interface is probably the better way to go.
<a href="https://github.com/ampron/rustlab" rel="nofollow">https://github.com/ampron/rustlab</a>
Interesting, though the C middleman isn't necessary if you can describe to Rust's FFI that mxArray is an opaque struct (I imagine the other regular functions in the MEX API are cakewalk for an FFI worth it's weight).<p>A while ago I wrote a mexFunction purely in Cython, and it was wondeful because Python was immediately available to work with (instead of C). The problem was that the numerical libraries on which NumPy builds often shared symbol names with MATLAB (such as svd, or hdf5) that differ in implementation resulting segfaults or corrupted data.
One thing that jumped out to me, and I haven't worked with Rust FFI enough to know this answer. Is the C library necessary? Since Rust is exporting the C interfaces directly, couldn't Matlab link directly against that?