Generally 100% Rust is the gold standard, followed by Rust wrapping some C library. The least preferable option would be invoking an external command and parsing its output. The reason for this is portability.

Pure Rust is going to be the most portable option as if it's written right it should work on any architecture and OS supported by Rust. If it's no-std it might even run bare metal.

The second most portable option is going to be wrapping a C library as now you're dependent on that library being available for a given architecture and platform.

The least portable option is invoking a CLI app and parsing its output. You're now dependent on that app being available for a given platform and architecture, but you're also going to be dependent on any differences of its arguments and output. Apple for instance is infamous for using their own unique flavor of most CLI apps (usually a variant of BSD versions, while GNU versions are typical on Linux or even Windows).

Here are some other reasons:

• users can install any version of a CLI command, so you could get weird breakage, whereas you control the version with a cargo dependency
• CLI commands can have variability with user configuration, whereas libraries typically don't

But each of those can also be a benefit:

• you probably don't need to patch your software if a security vulnerability lies in the CLI command, the user can just patch their system
• users being able to customize the CLI may make your app easier to write (i.e. you don't need to reproduce those same configuration options)

So it really depends on your target use case. But in general, a library is probably better for code you intend to share with others or put in production.

Another reason to use libraries is communication. Would you prefer to receive a GitCommitResult in your code, or have to parse the stdout of the subprocess? If you need complex communication with the other program, then it needs to provide rpc or some other form of inter-process communication. A library avoids this issue.

In my mind I think that doing an execution of an external program is fine in scritps, but for more robust programs you should use libraries. There are of course exceptions, I once used libsvn instead of just calling the svn binary (as you understand, this was a long time ago, when svn was till the way to version software). libsvn turned out to be the most horrible library, so for that it would have been better to call the binary instead. But, in general, avoid runtime dependencies and errors if possible, also libraries normally allows for much better error handling. So, I always use a library if available and not obviously horrible.

I can't speak for others, but personally, for anything that isn't intended to be hacky or something like a CI/CD script, I use a library where possible. Specifically with Rust, libraries are statically linked, so there's no need to worry about the interface/version being different on different machines at runtime, and the machine doesn't (usually) need to install a dependency for your program. Libraries which wrap a CLI tool and call out to it internally are still useful even if the CLI tool isn't statically linked since they already have all the glue to connect the code with the CLI tool set up, making it easier to use the tool usually.

This isn't always possible of course, but if you're calling out to something like git which has an extremely stable interface and has had all the features you need for many years, then the benefits of statically linking aren't nearly as high. Also, sometimes the dependency is just too complex to be a statically linked library (like if you need to call cmake or something). Still, if some kind of popular wrapper library for these exist, I use them where possible so I don't need to reimplement what the wrapper libraries already have.

Another aspect is that calling a cli command is way slower than a library function (in general). This is most apparent on short running commands, since the overhead is mostly fixed per command invocation rather than scaling with the amount of work or data.

As such I would at the very least keep those commands out of any hot/fast paths.