Sorry to hear, it's a bit of a rough situation with Flatbuffers and Rust. One possibility is to build an interface to the Flatbuffers data via flatcc (https://github.com/dvidelabs/flatcc) -- I wonder if these bindings are header-only like C++ and if that makes things any easier for you.
If you defined an API in Rust for reading and writing the Arrow metadata that does not expose any Flatbuffers-specific details, then once there is a production-grade Rust implementation of Flatbuffers, the implementation details could be swapped out without disruption. > my recent attempts at contacting the author have been unsuccessful Have you e-mailed the author directly or only pings on GitHub? Pings may not be making it to their inbox. Appreciate your efforts on this; I think we'll see a lot more work in data processing in Rust in the coming years. - Wes On Fri, May 18, 2018 at 9:21 AM, Andy Grove <andygrov...@gmail.com> wrote: > Hi, > > Now that the refactor I've been working on has been merged, the next > priority for me personally with the Rust implementation is getting IPC and > integration testing working. > > Unfortunately the official Flatbuffers Rust version is not available yet > and my recent attempts at contacting the author have been unsuccessful so I > have started working with this fork of Flatbuffers which has Rust support: > https://github.com/josephDunne/flatbuffers. > > I was able to generate code from Schema.fbs but it doesn't compile and I've > started filing issues and debugging this. > > Working with this fork isn't ideal but I don't see what other choice I > have, other than just waiting for the official project to support Rust. > > I'm interested to hear if anyone has any alternate suggestions. I know it > would be possible to wrap C code but I'd like to keep the Rust > implementation as a pure Rust project if possible. > > Thanks, > > Andy.
