Hacker News Reader

Comment by duckerude | Hacker News Reader

At least 500K comes from clap, the argument parsing library. That's how much true's size drops if you comment it out.

It's a lovely library. Generated help text with colors and line wrapping based on your terminal width, informative error messages that suggest corrections for typos, and a declarative model that lets you express subtle relationships between options. You don't get that from getopt.

But it's also pretty large. https://github.com/rust-cli/argparse-benchmarks-rs has some numbers.

(Disclaimer: I wrote one of the competitors on that page, lexopt. But I also use clap, depending on the project, and I'm happy with it.)

View on HN

500K to parse options is frankly too much...

In most software people will care more about helpful error messages and readable help texts than about half a megabyte of code size. Coreutils with its tiny frequently called binaries is an outlier where the size adds up, but that's not the norm.

Not sure how you are serious about your reply. PCs are a small market and a solution fitting them hardly represents a valid approach. There is an entire world of small devices that don't vomit terabytes of disk space.

One of the most attractive features of Linux is how it suits a large array of hardware. Replacing C solutions with some bloated bandwagon alternative is a bad idea.

Yes, if you write software for devices with megabytes of disk space then don't use Clap for argument parsing in your software. I'm not really sure how that's a criticism of Clap in general, or the rust coreutils specifically. Rust coreutils built as a single binary (as opposed to one binary per tool) is about 8MB. Anyone who is agonizing over 500kB of RAM or disk space is going to use BusyBox instead of either the GNU coreutils or a rust replacement for them. Why limit the implementation to satisfy the needs of somebody who wouldn't choose you anyways?

This thread inspired me—I found a way to remove 40K: https://github.com/clap-rs/clap/pull/3370

I'm sure it's possible to cut it more. It'll never be tiny, but it can be smaller than it is now.

Out of curiosity, why should each application implement line wrapping for terminals. That seems like a feature the terminal should implement, and from what I've read there is no standard way of getting the terminal size anyway.

The terminal isn't aware that you're, for example, using an indent because the help text of an option should appear indented from the option it's explaining. So the line wrap will go into the next line and ruin the readability.

Ah, that makes sense.

There's the TIOCGWINSZ ioctl which seems pretty standard.

The added compile times scared me off of pretty much all the bigger options. Like, six seconds? Wooooooof.

Reply on news.ycombinator.com