c-blake

cligen

Nim2018–2026

c-blake / cligen

cligen

Nim library to infer/generate command-line-interfaces / option / argument parsing; Docs at

Explore on GitHub Read Hacker News discussions

8Distinct people

57Mentions

0Explicit recommenders

584GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Nim library to infer/generate command-line-interfaces / option / argument parsing; Docs at

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

c-blake/bu · linked in 12 of the same discussions
c-blake/lc · linked in 2 of the same discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 5:05:26 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year57 dated mentions

Observed mentions: 2018-08-17 23:26:38 UTC to 2026-10-13 15:14:01 UTC.

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	1	0	1
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	0	1
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	8	0	8
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	8	0	8
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	10	0	10
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	12	0	12
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	5	0	5
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	10	1	9
2026 (partial)	2026-01-01 00:00:00 UTC	2027-01-01 00:00:00 UTC	2	0	2

What Hacker News says

8 sources

cb321·Dec 31, 2021

If the PL you are using already has named parameters with defaults then you can roll a CLI on top of it with a more well specified "spec" language (the PL itself) and with less work. There are a few Python packages for this and https://github.com/c-blake/cligen (which lets you add a CLI to an existing API with just one line of code). This is theoretically even possible for C++ with some kind of compile-time reflection API, but the way the C preprocessor works probably makes it hard to preserve structured comments for automatic documentation extraction. It was quite easy to do in Nim.

In Docopt

cb321·Nov 21, 2021

I got run times from the simplest single-threaded directory walk that are only 1.8x slower than git ls-files. (Min time of 10 runs with the git repo housed by /dev/shm on Linux 5.15.) The "simple" code is in https://github.com/c-blake/cligen/blob/master/cligen/dents.n... (just `dents find` does not require the special kernel batch system call module to be fast. That kernel module is more about statx batching but IO uring can also do that these days. For those unfamiliar with Nim, it's a high productivity, high performance systems language.) I believe that GNU find is slow because it is specifically written to allow arbitrary filesystem depth as opposed to "open file descriptor limit-limited depth". (I personally consider this over-/mis-engineered from days of bygone systems with default ulimits of, say, only 64 open fd's. There shoul

Read the rest

d at least be a "fast mode" since let's be real - file hierarchies deeper than 256..1024 levels, while possible, are rare and one should optimize for the common case or at least allow manual instruction that this case prevails. AFAIK there is no such "fast mode". Maybe on some BSD?) Meanwhile, I think the Rust fd is slow because of (probably counterproductive) multi-threading (at least it does 11,000 calls to futex).

In Git ls-files is Faster Than Fd and Find

cb321·Oct 29, 2021

This is roughly how https://github.com/c-blake/cligen/blob/master/examples/dups.... can work. There is little question that changing the scale of the problem very much lessons performance sensitivity to the hash.

In Meow Hash (2018)

cb321·Sep 7, 2021

When you have a standardized problem setting like the implicit loop in awk, n alternative to a whole new programming language is a simple < 100 lines of code program generator [1]. This design lets you retain easy access to large sets of pre-existing libraries as well as have a "compiled/statically typed" situation, if you want. It also leverages familiarity with your existing programming languages. I adapted a similar small program like this to emit a C program, but anything else is obviously pretty easy. Easy is good. Familiar is good. Interactivity-wise, with a TinyC/tcc fast running compiler backend my `rp` programs run sub-second from ENTER to completion on small data. Even with not optimizing tcc, they they still run faster than byte-compiled/VM interpreted mawk/gawk on a per input-byte basis. If you take the time to do an opt

Read the rest

imized build with gcc -O3/etc., they can run much faster. And I leave the source code around if you want to just use the program generator as a way to save keystrokes/get a fast start on a row processing program. Anyway, I'm not trying to start a language holy war, but just exhibit how if you rotate the problem (or your head looking at the problem) ever so slightly another answer exists in this space and is quite easy. :-) [1] https://github.com/c-blake/cligen/blob/master/examples/rp.ni...

In Awk: The Power and Promise of a 40-Year-Old Language

cb321·May 15, 2021

First, I like that you said "multicores" and not "multithreads". Default-sharing of all memory is overrated. Sometimes it is useful/necessary, but people reach for threads too readily, IMO. For multiprocessing (like Python's module of that name), you can roll your own little system in probably 100 lines of code or use something like this [1] with an example program [2]. For me, that toy program runs 1.5-2x faster than ripgrep on the same (admittedly limited) problem on Linux. { I suspect this perf diff is due to mmap IO being faster than syscall IO due to SIMD register use as discussed here [3], but this deserves deeper investigation than I have time for right now. If my hunch is right, that may constitute further argumentative support for not leaping to threads even if the programming language "makes them 'easy'", though. } As for th

Read the rest

reads/parallelism with shared memory in Nim..Honestly, there is probably too much to recap. Weave [4] would be a good place to start reading, though, or searching the Nim Forum. [1] https://github.com/c-blake/cligen/blob/master/cligen/procpool.nim [2] https://github.com/c-blake/cligen/blob/master/examples/grl.nim [3] https://news.ycombinator.com/item?id=24842648 [4] https://github.com/mratsim/weave

In Nim 2.0 thoughts

cb321·Mar 17, 2021

Nim [1] has cligen [2]. An output binary size for the trivial: proc f = discard import cligen dispatch f is about 708 KiB on Linux, 621 KiB stripped. And if you like colors, hldiff [3] is not a terrible example. [1] https://nim-lang.org/ [2] https://github.com/c-blake/cligen [3] https://github.com/c-blake/hldiff

In Writing Small CLI Programs in Common Lisp

cb321·Mar 12, 2021

Sometimes endowing existing syntax with richer semantics requires almost no documentation because things "just work". For example, cligen [1] uses a macro to synthesize an argv parser -> call dispatch CLI system. It could almost have been a template but it needs to loop over parameters more than once (and then grew a lot of features). Anyway, since Nim has user-defined new operators, using those might also bother some. E.g., there could be a proc `=>` meaning something very different from that sugar module macro of the same name. Really, these work just like other procs modularity-wise. The syntax/grammar does not actually change, though. It's just flexible in the first place. These complaints sound more like excuses to me. Every language has calls, styles, idioms, etc. you need to learn as a client of whatever it is you're calling/

Read the rest

doing. And every language has quirky syntax corners. E.g., many are unaware that C lets you say "(a,b,c,d)" { which evaluates but ignores the result of "a,b,c" }. Yet you still often hear people proclaim how simple C syntax is. "Compared to what?", I guess (e.g. C++). I do get where you are coming from "overloading"-wise - not just operators, but also regular procs (which in Nim are the same...there is just a proc `<`). When learning an alien language/code-base/libraries it really helps to have jump-to-definition. Nim via nimsuggest has great support for this if you configure your editor (vim, emacs, VisualStudio Code, etc.). You may have skipped that step but might love it more if you did it next time. nimsuggest can be aware of local and global --path modifications and the type context of the jump-to-definition. So, it can do a much better job than, say, ctags. (and yes, nimsuggest works for all the various definition types like macros, templates, etc., even the ones named like an operator such as `<`). [1] https://github.com/c-blake/cligen

In Patten Matching in Nim

cb321·Feb 22, 2021

Also, I am not sure what counts as "in production" but on literally a daily basis I use about 15 different command line utilities I wrote in Nim using cligen [1] (EDIT: Really I have written several dozen but only about 15..20 are useful every day). There are always compiler bugs/things to workaround (as with any language), but Nim has been pretty usable for years. [1] https://github.com/c-blake/cligen

In Go is not an easy language