As ripgrep's author, I think binary size is important, but I think it's simultaneously a niche concern. Saying that they need to be tiny is I think a pretty big overstatement. They might need to be tiny in specific use cases, i.e., niche. But the 99% use case is probably that most users don't care. ripgrep's binary size is already pretty meh (especially compared to similar tooling that relies more heavily on dynamic linking). My guess is that if its binary size doubled even from what it is today, few would notice and even fewer would care.
AFAIK, ripgrep's biggest deployment is through VS Code, by far. Nobody is going to notice that some part of VS Code is now using 8MB instead of 4MB (or whatever it is, I think it's around that). It's largely a non-issue from my perspective.
Now, compile times... That's a different story. I'll happily complain about that one.
> But the 99% use case is probably that most users don't care.
For 1 really good utility like ripgrep, yeah. You'll convince many people to use it based on its merits. You might even have 5 or 10 of these utilities, if they're really good.
But for Linux system builders, for the things that go into standard distributions, where you need hundreds of such utilities, Rust CLI binaries are simply not sustainable. Not for size, not for security, not for simplicity of bootstrapping, nor, as you said, for compiling an OS from sources.
You will be able to get ripgrep into many distributions, but it will be more unlikely to become one of the tools installed by default for that reason.
> You will be able to get ripgrep into many distributions, but it will be more unlikely to become one of the tools installed by default for that reason.
Oh I don't agree with that all. It might be a factor, but it isn't going to be installed by default because grep will already be there. Unseating a POSIX user land in a Linux distro is not going to be blocked just on binary size IMO.
I also think what you're saying is not inconsistent with what I'm saying. The default tools installed on a Linux distro is a niche use case. ripgrep doesn't need to be installed by default in any Linux distro in order to be successful.
If you're setting out to build tools to replace, say, a GNU user-land to fulfill POSIX (or provide an entirely different sort of user experience), then binary size is probably the least interesting thing to overcome. And if you "try" hard enough, Rust binary sizes can be reduced quite a bit. ripgrep being 4MB is the result of me not caring at all about binary size (beyond stripping debug info). But this is a niche goal IMO, and IMO does not support your initial claim:
> And for CLI tools, you need those to be tiny.
Notice how if you instead said:
> And for CLI tools that are installed by default on a Linux distro, you need those to be tiny.
then it takes almost all the air out of your comment.
AFAIK, ripgrep's biggest deployment is through VS Code, by far. Nobody is going to notice that some part of VS Code is now using 8MB instead of 4MB (or whatever it is, I think it's around that). It's largely a non-issue from my perspective.
Now, compile times... That's a different story. I'll happily complain about that one.