3 ms·

It seems better/easier if these tools just exposed an API so they could be used as a library directly without sticking exec wrappers in.

• burntsushi 3y ago
  ripgrep does expose a library. It's just vast, complex and exposes an API that is lower level than what the CLI provides. It's a lot easier to just do `rg --json` and be done with it. ripgrep has on the order of 100 flags. I don't have the bandwidth to maintain both a CLI and a stable library interface for all of that. So while it might seem better to you, there are realities that make it difficult to do given constrained time and resources.
  • nijave 3y ago
    Tbh I'm surprised no one is already maintaining a decent abstraction (or maybe they're just not discoverable). Afaik openssl is the same way and there's some high-level libraries that are common (although I suppose some of that is built into language stdlibs)
    • burntsushi 3y ago
      openssl is likely categorically different. When you need SSL, there isn't too much choice. But when you need to search stuff, especially in a specific case, you often don't need the full functionality of something like ripgrep or even its speed. Often, just iterating over lines and doing a regex search for each is Good Enough. Bottom line is that a naive solution can get you a lot of mileage, where as there really is no naive and simplr solution to SSL. On top of that, ripgrep has a `--json` flag with a pretty simple format. Running another process is often not a Big Deal, and thus, there is another off ramp to avoid the complexity of ripgrep's libraries that doesn't really exist for SSL.
• yjftsjthsd-h 3y ago
  Sure, if we could have every program built as a library that then had a front end wrapped around it that would be great. However, in practice that's not particularly common.
  • nijave 3y ago
    I mostly meant around ag/ripgrep since I thought these optimized search tools were pretty popular & widely used.