[cb321]

I don't know about all your other questions, and I realize your post was more about "why Rust?" rather than "why not Nim?", but that said the https://github.com/c-blake/cligen Nim CLI framework seems much lower effort / ceremony than even Rust's `argh` and is just about as old as `clap` (both cligen & clap started 8 years ago in 2015 - Rust argh is much newer).

There are over 50 CLI utilities in Nim at https://github.com/c-blake/bu, many of which do something novel rather than just "re-doing ls/find/cat with a twist". While they are really more "ls/ps construction toolkits" with some default configs to get people going, I think https://github.com/c-blake/lc and https://github.com/c-blake/procs are nicer than Rust alternatives. I mention these since you seem interested in such tools.

[joshka]

It's more that those tools were what come to mind when I specifically think of my exposure to the existence of rust. Its perhaps not that the tools were there, but that they were well known (and known for being written in rust).

Anecdatapoint - I've never heard of literally a single one of the utilities listed on the bu page.

Regarding cligen, right from the start clap wins on producing idiomatic output. Compare: https://github.com/c-blake/cligen#cligen-a-native-api-inferr...

    Usage:
      fun [optional-params] [args: string...]
    An API call doc comment
    Options:
      -h, --help                    print this cligen-erated help
      --help-syntax                 advanced: prepend,plurals,..
      -f=, --foo=    int     1      set foo
      -b=, --bar=    float   2.0    set bar
      --baz=         string  "x"    set baz
      -v, --verb     bool    false  set verb

With: https://docs.rs/clap/4.3.8/clap/#example

    $ demo --help
    A simple to use, efficient, and full-featured Command Line Argument Parser

    Usage: demo[EXE] [OPTIONS] --name <NAME>

    Options:
      -n, --name <NAME>    Name of the person to greet
      -c, --count <COUNT>  Number of times to greet [default: 1]
      -h, --help           Print help
      -V, --version        Print version

    $ demo --name Me
    Hello Me!

Aesthetics matter, and I know which one I prefer by a long shot. Things like that leak through into every "rewrite it in rust" cli. There's a lot of rust things that just seem to make good decisions like this easy.

[cb321]

There is a way to disable the type column and embellish parameter descriptions or even replace the entire generated string, all at gradual investment of time, though docs can always be better. I disagree that it's a bad default since types help users know `count` is not a float (e.g. count per minute). How many times has there been some "delay" parameter you weren't sure could take fractions of a second?

Anyway, cligen needs just 1..2 lines of code (`import cligen; dispatch fun`) to infer & generate all that from a pre-existing proc/func. Very low ceremony. `clap` & `argh` have more intricate specification/convention languages to learn, like most arg parsing / dispatching tookits.

CLI tools are a diverse lot. What help text similarity exists largely flows from toolkits or their defaults. E.g., Rust `argh` output differs (at least on their home page) from Rust `clap` in showing default values. So, your own 2 reference points already disagree on that default, at least in their examples (likely all 3 can say "whatever" with work).

This diversity is one reason why inflammatory rhetoric like "wins" or "good decisions" for ultimately context-specific (&tough!) judgement/aesthetic calls about defaults is unhelpful. There may be a little "back pressure" from users and from completion systems like Zsh's - but if you look into Zsh compctl you will see dizzying diversity of CL syntax & help formatting. The cligen defaults at least let you use _gnu_generic (as can both `clap` & Rust `argh`, I'd guess).

There are various reasons for all that diversity. Users after running -?/-h/--help/etc. do prioritize "the information" (for some value of that) over the formatting, as with most documentation. The diversity is also not going anywhere, as evidenced already by Rust `clap` & `argh` discrepancies. Devs just like different things. The docopt people like to start closer to free-form text (but do have a help parsability requirement).

I did not expect you to be aware of bu/ tools. I just thought you might be interested in CLI tools outside a standard repetitive bubble. Most people don't seem to like CLI tools like you & I do.

Using Rust in firefox was likely the most persuasive app for "can be used for real things", as has been mentioned (by almost everyone). I kinda doubt `clap` (inspired much of | saved much dev time for) `rg/ripgrep`, `exa`, `fd`, or whatever, for example (though it probably did help for greater uniformity).

[burntsushi]

A fun fact, ripgrep used docopt for arg parsing in its original release: https://github.com/BurntSushi/ripgrep/blob/b1c52b52d6eed5b24...

I switched to Clap pretty quickly after the initial release though. Like a couple months: https://github.com/BurntSushi/ripgrep/pull/233

I do currently have loose plans to move away from Clap to lexopt. But I don't know when or if that happens.