This is an outstanding library which is more of a CLI framework.
It's seriously optimized and includes ready to use modules which are alternative to Nim's standard library or more tailored/opinionated interfaces for basic POSIX software building blocks.
Don't skip going over examples[1]. All of those are fully functional programs, some are pretty niche, but all are very usable and, I bet @cb321 will confirm, in some cases are competitive with widely-used alternatives.
There hasn't been a ton of benchmark comparisons. From memory, on what remains in examples/:
The cligen/dents stuff is faster than anything not so enabled with a new kernel call and some perf stuff mentioned right in the comments there, but Linux has moved to blocking installing syscalls from modules.
I've timed gl/grls against ripgrep favorably, but it's obviously a very simple pattern subcase. Mostly those were to demo cligen/procpool.
examples/cols was faster than awk or xsv for me (which has really moved to https://github.com/c-blake/bu now along with several others like `rp` - which is kind of a "concept piece" showing that any command-line is kind of a "language" already and with just a little codegen magic you can beat awk at most of its own games: https://github.com/c-blake/bu/blob/main/doc/rp.md).
Some subthread in one of the hundreds of closed issue threads got into a comparison of dups and jdupes ( https://github.com/c-blake/cligen/issues/99#issuecomment-485... ) where Jody shows up. I mean, in my test cases dups fared well, but on what many would call the "boring non-IO bound case". For IO bound cases things rapidly depend a lot on your host OS & devices.
I should say that "the point" of most of these things was not caffeine-fueled rage optimization, but more to show how easy it is to get performance & functionality out of Nim. Almost all are much smaller programs (perhaps with many fewer features) than their competing programs. But such catering to The Unix Philosophy felt like it fit well with a CLI toolkit. { Even sys_batch is like a 30 lines of C virtual machine for inside Linux instead of untold 10s of thousands for eBPF & IO uring. While porting to other arches would be more, that 30 lines could probably stay the same. }
cb321 · 1d ago
There is actually a lot more in cligen/ than only CLI generation from proc signatures. https://c-blake.github.io/cligen/ covers some of that.
It's seriously optimized and includes ready to use modules which are alternative to Nim's standard library or more tailored/opinionated interfaces for basic POSIX software building blocks.
Don't skip going over examples[1]. All of those are fully functional programs, some are pretty niche, but all are very usable and, I bet @cb321 will confirm, in some cases are competitive with widely-used alternatives.
https://github.com/c-blake/cligen/tree/master/examples
The cligen/dents stuff is faster than anything not so enabled with a new kernel call and some perf stuff mentioned right in the comments there, but Linux has moved to blocking installing syscalls from modules.
I've timed gl/grls against ripgrep favorably, but it's obviously a very simple pattern subcase. Mostly those were to demo cligen/procpool.
examples/cols was faster than awk or xsv for me (which has really moved to https://github.com/c-blake/bu now along with several others like `rp` - which is kind of a "concept piece" showing that any command-line is kind of a "language" already and with just a little codegen magic you can beat awk at most of its own games: https://github.com/c-blake/bu/blob/main/doc/rp.md).
Some subthread in one of the hundreds of closed issue threads got into a comparison of dups and jdupes ( https://github.com/c-blake/cligen/issues/99#issuecomment-485... ) where Jody shows up. I mean, in my test cases dups fared well, but on what many would call the "boring non-IO bound case". For IO bound cases things rapidly depend a lot on your host OS & devices.
I should say that "the point" of most of these things was not caffeine-fueled rage optimization, but more to show how easy it is to get performance & functionality out of Nim. Almost all are much smaller programs (perhaps with many fewer features) than their competing programs. But such catering to The Unix Philosophy felt like it fit well with a CLI toolkit. { Even sys_batch is like a 30 lines of C virtual machine for inside Linux instead of untold 10s of thousands for eBPF & IO uring. While porting to other arches would be more, that 30 lines could probably stay the same. }