After the announcement of the open-sourcing of FoundationDB I decided it would be really nice to have some Rust bindings. I might have use of this in some other projects, so it would be really neat. Anyway, I started, and then @yjh0502 found what I was doing and contributed most of the interesting work. I only documented the excellent work done there, and added some ease of use things, and licenses, etc.
Anyway, I can't really take any credit for this, but I'm excited to get to announce this weekends efforts! And thank you, Apple, for such a high-quality release of an opensource project. You should be able to follow the docs here: foundationdb - Rust or here: https://crates.io/crates/foundationdb
I took a look at this in the weekend as well. Were you able to test the bindings using the docker image? I kept getting unresolved symbols with std::basic_istream::ignore() which should be defined in libstdc++.a but wasn't for some reason.
I haven't been using a docker image. So I'm not sure of the error you're running into. We didn't do any crazy
configuration, I basically used the bindgen example as is. It appears to work on Linux and macOS without issue:
We switched to checking in the generated file from a Linux system, which was cross-system compatible. I haven't gone back yet to see if there are some whitelist/blacklist options to bindgen that might make the file as produced on macOS function on Linux as well.
I'm happy to announce that we've got a 0.2 release of the API complete. Again, much of the low level work was completed by @yjh0502, see the changelog below for all the APIs added. This release also brings the implementations for Tuple::{decode, encode}, which @rushmorem had huge hand in making sure implemented the Rust style guidelines appropriately. There was a lot of churn on the Tuple interfaces, but I think we finally landed on a decent implementation.
In addition, the FoundationDB bindingstester and benchmark suites have been integrated with the library by @yjh0502. These should prove that this implementation is compliant with the other client libraries.
Again, as a warning to early adopters, many of these interfaces are still in flux, and will be improved in the future. For example: things like Subspace, KeySelector, RangeOptions, etc. still need to gain borrowed counterparts, that should make for fewer allocations for those types. Also, I didn't capture API changes at a granular level in this changelog, apologies if this breaks any existing implementations. That being said, we hope you'll try it and give us your feedback. Thanks!