bu

I think Nim is great for small CLIs. Some examples are over at: https://github.com/c-blake/bu . To quantify "small", using tools themselves in bu/ (and Zsh *): wc -l --total=never **.nim|cols 1|cstats ms q.05 q.95 75.5 +- 5.7,22.5,175.25 So, around 1..2 pages for a 70-row terminal window, with a 5th & 95th Parzen interpolated quantiles of 22.5 and 175.25 lines.

200 lines of Nim [1] seems to run about 9X faster than the 8000 lines of C in fdupes on a little test dir I have. If you need C, I think jdupes [2] is faster as @TacticalCoder points out a couple of times here. In my testing, `dups` is usually faster than `jdupes`, though (but usually only ~1.5..2.0X faster in hot cache settings -- for this problem "really slow" usually comes from IO, though). [1] https://github.com/c-blake/bu/blob/main/dups.nim [2] https://github.com/jbruchon/jdupes

You better off with using a compiled language. If you interested in a language that's compiled, fast, but as easy and pleasant as Python - I'd recommend you take a look at Nim: https://nim-lang.org. Nim has cligen library to generate and parse arguments: https://github.com/c-blake/cligen And to prove what Nim's capable of - here's a cool repo with 100+ cli apps cligen author wrote in Nim: https://github.com/c-blake/bu

20 milliseconds? On my 7 year old Linux box, this little Nim program https://github.com/c-blake/bu/blob/main/wsz.nim runs to completion in 109.62 +- 0.17 microseconds when fully statically linked with musl libc on Linux. That's with a stripped environment (with `env -i`). It takes more like 118.1 +- 1.1 microseconds with my usual 54 environment variables. The program only does about 17 system calls total, though. Additionally, https://github.com/c-blake/cligen makes decent CLI tools a real breeze. If you like some of Go's qualities but the language seems too limited, you might like Nim: https://nim-lang.org. I generally find getting good performance much less of a challenge with Nim, but Nim is undeniably less well known with a smaller ecosystem and less corporate backing. EDIT: I make only observations here, not demands. Another o

No problem. It might also bear mentioning that if one is willing to learn more specialized tools, even less key-downing is possible, such as (using https://github.com/c-blake/bu/blob/main/doc/cols.md): grep ^[A-Za-z]|cols 2 You just lose that row number in the original input coordinates feature of Ben's example which could probably be recovered with `grep -n` & `cols -d' :'`, etc., etc. In exchange, you can say `cols 2:5` to get a block of columns trivially. And then, of course, once you have any oft-repeated atom you can save it in a tiny script/etc. A lot of these choices come down to atom discovery & how willing/facile someone is juggling/remembering syntax/sub-languages. In my experience, willingness tracks facility and both are highly variable distributions over the human population.

Often whole program generation in a prog.lang (& ecosystem!) that you already know can substitute for a new prog.lang. Python even has eval. You may be interested in: https://github.com/c-blake/bu/blob/main/doc/rp.md You can actually get pretty far depending upon boundaries with the always implicit command-option language (when launched from the shell language, anyway). For example, Ben's example can be adapted to: rp -m^\[A-Za-z\] 'echo nr," ",s[1]' which is only 5 more characters and only 3 more key downs (less SHIFT-ing) than the space-optimized version of his `awk`. { key downs are, of course, just a start to a deep rabbit hole on HCI ergonometrics ending in heatmaps, finger reach/strain/keyboard layouts, left-right hand switching dynamics, etc., but they seem the most portable idea. } Nim is not Python - it is actually a bit

If you find this article interesting and are curious about Nim then you would probably also be curious about https://github.com/c-blake/cligen That allows adding just 1-line to a module to add a pretty complete CLI and then a string per parameter to properly document options (assuming an existing API using keyword arguments). It's also not hard to compile & link a static ELF binary with Nim.. I do it with MUSL libc on Linux all the time. I just toss into my ~/.config/nim/nim.cfg: @if musl: # make nim c -d:musl .. foo static-link `foo` with musl cc = gcc # --opt:size trades more speed gcc.exe = "musl-gcc" # NOTE: This also works as a .. gcc.linkerexe = "musl-gcc" #..per-module foo.nim.cfg passL = "-static -s" @end Lisp is often cited as one of Nim's ins

You might consider: https://github.com/c-blake/bu/blob/main/doc/cols.md That's in Nim, though that may not be much a barrier. (There may also be other tools in bu/ of interest.)

Of possible interest - instead of making a whole new programming language like awk, you can also just systematize generating code for an existing one with a command-line harness. This can even stay terse & keep a fairly fast edit-test turnaround in a fully statically typed language like Nim: https://github.com/c-blake/bu/blob/main/doc/rp.md

This sounds like a job for what standard C calls "popen". You can do import posix; for line in popen("ls", "r").lines: echo line in Nim, though you obviously need to replace `echo line` with other desired processing and learn how to do that. You might also want to consider `rp` which is a program generator-compiler-runner along the lines of `awk` but with all the code just Nim snippets interpolated into a program template: https://github.com/c-blake/bu/blob/main/doc/rp.md . E.g.: $ ls -l | rp -pimport\ stats -bvar\ r:RunningStat -wnf\>4 r.push\ 4.f -eecho\ r RunningStat( number of probes: 26 max: 31303.0 min: 23.0 sum: 84738.0 mean: 3259.153846153846 std deviation: 6393.116633069013 )

On Unix, you might try Nim (https://nim-lang.org) with https://github.com/Vindaar/shell and there are a slew of pipeline-y/Unix-y utilities over at https://github.com/c-blake/bu Nim is statically typed and (generally) native-compiled, but it has very low ceremony ergonomics and a powerful compile-time macro/template system as well as user-defined operators (e.g., you can use `+-` to make a constructor for uncertain values so that `9 +- 2` builds a typed object as in https://github.com/SciNim/Measuremancer .

You can probably do something that creates as many FIFOs as you have parallelism and just be careful about emitting whole records like https://github.com/c-blake/bu/blob/main/doc/funnel.md . That one's Nim, but the meat is only like 50 lines and easily ported to C like your progress tool. ( EDIT: and it will also probably be drastically lower overhead than `parallel` which has over 70X worse time overhead and 10X the RAM overhead of tools written in fast, native-compiled languages: https://github.com/c-blake/bu/blob/main/tests/strench.sh )

Nim is terse yet general and can be made even more so with effort. E.g., You can gin up a little framework that is even more terse than awk yet statically typed and trivially convertible to run much faster like https://github.com/c-blake/bu/blob/main/doc/rp.md You can statically introspect code to then generate related/translated ASTs to create nearly frictionless helper facilities like https://github.com/c-blake/cligen . You can do all of this without any real run-time speed sacrifices, depending upon the level of effort you put in / your expertise. Since it generates C/C++ or Javascript you get all the abilities of backend compilers almost out of the box, like profile-guided-optimization or for JS JIT compilation. EDIT: There really is much more, as with any system - I was just trying to give a flavor of what appeals to me.

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.

You are welcome. Thanks are too rarely offered. :-) You may also be interested in word stemming ( such as used by snowball stemmer in https://github.com/c-blake/nimsearch ) or other NLP techniques, but I don't know how internationalized/multi-lingual that stuff is, but conceptually you might want "series of stemmed words" to be the content fragments of interest. Similarity scores have many applications. Weights on graph of cancelled downloads ranked by size might be one. :) Of course, for your specific "truncation" problem, you might also be able to just do an edit distance against the much smaller filenames and compare data prefixes in files or use a SHA256 of a content-based first slice. ( There are edit distance algos in Nim in https://github.com/c-blake/cligen/blob/master/cligen/textUt.... as well as in https://github.com/c-blake/s