In answering this, I'd look beyond just the language features and look at the background of how it caught on. What apps were built first. When did the "Rewrite it in rust" mantra take hold. What impact did <system tool> but with colors / nice cli / sensible defaults have on things (e.g. fd / exa / lsd / bat / ...)? What libraries being available made it easy (clap / argh)?
Then look at how the community was built (e.g. Mozilla / conferences / forums etc.)
I've only recently started writing rust (after years of C#, Java, JavaScript, Ruby, Python, and a variety of other languages), and once I got past the basics of understanding borrow checker issues I love it as a language. Personally (for reasons unknown) I prefer brackets over indentation based languages, so Nim is a pretty hard sell there.
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.
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.
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
$ 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.
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).
Then look at how the community was built (e.g. Mozilla / conferences / forums etc.)
I've only recently started writing rust (after years of C#, Java, JavaScript, Ruby, Python, and a variety of other languages), and once I got past the basics of understanding borrow checker issues I love it as a language. Personally (for reasons unknown) I prefer brackets over indentation based languages, so Nim is a pretty hard sell there.