[WIP] Rust POC with `Maturin`

[nph4rd]

Description

This PR is to test out the integration of a Rust "backend" for SyMPC (following work from #245), with Maturin as its binding framework.

Update: So far, this PR has got the most basic set-up, following the structure in the feature/rust branch from PySyft.

Some things to do:

• [ ] Test the binding of some basic Python functionality. We already have a full project, sycret that does this, so we could probably recycle some stuff from there.
• [ ] Write Rust tests. I think there are no Rust tests so far (05-07-21), but this is definitely something that we should have so that we can integrate the code seamlessly.

Affected Dependencies

Dependencies will be affected but this is not yet clear, so will update this section later.

How has this been tested?

• Tests are running fine so far, and we can successfully run maturin develop & cargo test so everything's good up 'til this point.

Checklist

• [x] I have followed the Contribution Guidelines and Code of Conduct
• [x] I have commented my code following the OpenMined Styleguide
• [x] I have labeled this PR with the relevant Type labels
• [x] My changes are covered by tests

[nph4rd]

@madhavajay @gmuraru - in terms of integration, what do you think would be best: to start adding part of the code-base bit by bit (different PRs) or to have one PR with all of the Rust "backend"? This is more of a long-term thing I guess but it would be nice to foresee that.

[tholop]

Nice! One small thing: I feel that the structure of this kind of Maturin project can be a bit confusing.

Here, it seems that we will have SyMPC/src/sympc/ for the Python code, and SyMPC/src/src/ for the Rust code. That's odd. Also, The Rust tests are in the main lib for this PR, but we might want to put them in their own directory later (the Sycret repo looks quite weird with sycret/test/ for the Python tests and sycret/tests/ for the Rust tests).

One suggestion would be to do something like: SyMPC/src/python/ and SyMPC/src/rust/ for the Python/Rust source code, and do the same thing for the tests with SyMPC/tests/python/, SyMPC/tests/notebooks/ and SyMPC/tests/rust/.

[nph4rd]

Here, it seems that we will have SyMPC/src/sympc/ for the Python code, and SyMPC/src/src/ for the Rust code.

Indeed, I left it like that because it's the same structure as the one in PySyft. Although, I agree that it can be a bit confusing. Interested in reading what @gmuraru and @madhavajay think about that.

The Rust tests are in the main lib for this PR, but we might want to put them in their own directory later

Yes! Absolutely. Agree 💯 - I left it like that because it was the default when running cargo init --lib but I plan to change it in the near future.

Thanks for these comments @tholop!

[nph4rd]

@tholop - I've moved the Rust tests to a separate folder. Depending on what the final structure, this folder might stay there or be at the root of the project, along with the Python tests.

[gmuraru]

Could we also have a basic function added and called in the Python code? I am thinking at the ispointer function.

[nph4rd]

Could we also have a basic function added and called in the Python code? I am thinking at the ispointer function.

Yes - I am thinking of adding functionality to "prove" that this works. I think is is_pointer might be a good function to test. I'll try with that. However, I guess the real advantage of having a Rust backend would be to make computation more efficient, so it would be good to discuss as a team whether we will, indeed, want to port some of the code-base to Rust and, if so, which parts.