e-dant/watcher

Consider Rust Bindings

Opened this issue · 4 comments

I once rewrote this project in Rust to explore a safer language. Because this project is a thin, uniform wrapper around other unsafe systems, the rewrite wasn't safer.

It did turn out to be, in this project's case, a much more usable, ergonomic and mature ecosystem for

  • Asynchronous APIs
  • Packaging and cross-compilation
  • Language bindings
  • CLI development

All of which are things I want to work on more.

A Rust wrapper, without changing our underlying implementation, might do the trick.

It's not clear to me how much people rely on or want this, though.

I don't want to persuade you one way or another but to give you a little bit of information on why I chose your library.

All of the dependencies the project I work on uses C/C++ libraries and any we need to build, are submoduled (or code copied) into the code base and built as part of our project. This means that a rust implementation that required a rust compiler (I have not used rust?) would not be usable. I am not sure how common our use case is.

I picked your library because there weren't a lot of other options in C++ that were efficient and modern. Qt has a filesystem watcher but has a lot of additional details making it a lot to include when we don't need its main focus (UI), fswatch (we need multi-platform support but it only supports Linux), and watchman (may be fine but seemed overly complicated from their docs from what I recall?). I believe there was one other but it didn't even use C++11 and seemed to have some bigger concerns.

My change that uses this library isn't even merged yet and even if it would be, I don't want to come across as pressuring you. I do really appreciate this library and am sad there aren't more people praising it. It's for that reason I wanted to give my perspective as a user.

Best of luck in whatever you decide and thanks again for all your previous help!

Your feedback is meaningful. We don't need to do a rewrite in Rust.

Another path we can go is just wrapping it in a little shared library with a C abi. We can use that from a lot of languages, Rust included.

I do think that the easiest way to make the CLI more "fully featured" and friendlier to the user is leveraging the Rust ecosystem. (It's of course possible in any language, but Rust has some particularly good libraries for CLI development.)

The above won't change the existing C++ implementation at all. Still a header-only library with a small API.

I updated this ticket's title and description.

Thank you.

My change that uses this library isn't even merged yet

Can you elaborate on that? It might have gotten lost in the mix, but I thought we got them in 0.11.0 link to changelog

Can you elaborate on that?

Sorry if I wasn't clear, I meant my change to use this library in another project.