Rust and C++: A relationship built to last?

[ryneeverett]

There are two main questions here:

1. Should the Rust Taskchampion library live within the same repo as the C++ Taskwarrior CLI application?
2. Should the Taskwarrior CLI eventually be phased out in favor of a CLI written in Rust?

I suspect these questions factor into each other in various ways and the ramifications aren't entirely obvious. Some considerations:

• There are open questions about how the relationship will work whether or not they stay in the same repo. Will there be 1:1 releases? Will you be able to use different versions of taskchampion with a single release of taskwarrior? Etc.
• If split, that introduces more friction in implementing breaking changes to the Rust API because there has to be a corresponding pull request in both repos and once they are merged both will have to use later revisions than that commit in order to be compatible. If a high level of stability in taskchampion is desirable though, maybe that friction is a good thing.
• If C++ is phased out in favor of Rust (2), the transition story might be different whether they stay or split (1). If they stay, it seems like taskchampion might assume more and more of the functionality over time until nothing but commands/ remains in C++. If they separate, it seems more likely somebody will eventually create an alternative Rust cli based on the taskchampion library to completely replace taskwarrior.
• Does spanning the C++/Rust ecosystems mean there are more potential contributors (C++ devs OR Rust devs) or fewer (C++ devs AND Rust devs). While the truth is probably somewhere in between I would suspect it's closer to the latter.

Personally, I'm biased on (2) because I'm more comfortable with the Rust ecosystem and I find the C++/Rust compatibility layer to be the most confusing part of the current code base. The normal tooling I would use to follow foreign languages doesn't help because it doesn't seem to be able to follow these interfaces either.

[djmitche]

I wrote some comments in #3143 that, I suspect, led to this discussion. Copy/pasted here:

• I am inclined to move Taskchampion out to its own repo (e.g., GothenburgBitFactory/taskchampion). There are a few reasons:
  • The build-system integration is not great, and I think doing better would require invoking rustc directly from CMake, which would lose a lot of the Rust-y niceties of cargo and make this more like "some Rust code in a C++ app" than "a Rust library with a C++ CLI"
  • Splitting up CI for the two would help focus our attention -- the dependabot alerts are obviously all for Rust!
  • Separate repos would help to encourage a nice clean isolation between the two, so Taskchampion stays useful for non-Taskwarrior embedders instead of growing Taskwarrior-specific APIs.

So, I have a minor preference to answer "no" to the first question. But I'd prioritize my own work toward a 3.0 release. I do not think we should try to rewrite the CLI in Rust -- @dbr and I had a go at this and it's hard to do. It would be even more difficult to replicate Taskwarrior's CLI "bug for bug", so that existing automation around Taskwarrior could continue to work (we didn't even try this).

To @ryneeverett's considerations:

• I'd like TaskChampion to be relatively stable, and at any rate follow semver. Taskwarrior can treat it like any other app would treat a dependency. I admit that's a novel idea for a C++ app, but familiar from other languages.
• I think some friction in implementing breaking changes in the Rust API is (or soon will be) a good thing.
• (no comment)
• I vaguely suspect that having both languages in the same repo is intimidating for people who only know one of them (even if any particular change would likely only touch one of the two languages). With two repos the story is "a regular Rust library that is depended on by, among other things, a C++ app" and "a C++ app which calls out to a shared library".

I made the Rust/C++ compatibility the way I did because I didn't know the "right" way. I figured the best way to find the right answer is to give a wrong answer, but that strategy doesn't seem to have worked this time (maybe it only works on Twitter?). I got a little bit of better advice at RustConf this year, but again it seems like I should prioritize releasing 3.0 over re-implementing the FFI.

[ryneeverett]

No disagreement with anything here, but wanted to note that I totally agree (2) is way out of scope for taskwarrior-3.0. I was thinking much longer term.

• (no comment)

Oh, but you did comment:

I do not think we should try to rewrite the CLI in Rust -- @dbr and I had a go at this and it's hard to do. It would be even more difficult to replicate Taskwarrior's CLI "bug for bug", so that existing automation around Taskwarrior could continue to work (we didn't even try this).

To me that says that if the CLI were to be rewritten in Rust, the approach to take would not be gradual but a complete rewrite, complete with its own breaking changes. Separating the repo and increasing the friction on breaking taskchampion API changes makes this easier.

I made the Rust/C++ compatibility the way I did because I didn't know the "right" way. I figured the best way to find the right answer is to give a wrong answer, but that strategy doesn't seem to have worked this time (maybe it only works on Twitter?). I got a little bit of better advice at RustConf this year, but again it seems like I should prioritize releasing 3.0 over re-implementing the FFI.

I hadn't considered that there might be a better way for Rust/C++ to coexist and perhaps naively assumed this was as good as it gets. Improving this might be a good compromise.