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, 6:36:16 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

10 sources

cb321·Dec 30, 2022

Nim has impressive compile-time reflection which with its syntax macro system can (some of the time) get you similar powers to Python's dynamic reflection. E.g., https://github.com/c-blake/cligen instead of `autocommand` or `click` or `argh` or you name the automatic CLI generator, only with full C-like speed for your programs and a very low effort FFI to C. People have done web frameworks, too, but I do not know them well enough to compare to Django. Perhaps someone else could follow-up. Compile times are not the 25-50 ms of a Python interpreter startup, but they are similar to the 250-500 ms of a Go or D compile, at least for small light on metaprogramming loops kinds of programs, and with, say, the TinyC tcc backend. Of course, big frameworks take a long time to import (or to compile). So, your comparison mileage may vary. And onc

Read the rest

e "ready to go" and finished a Nim program can start up in sub-millisecond time like any C program (esp. if statically linked).

In Why I'm still using Python

cb321·Dec 27, 2022

If you want to be more DRY (do not repeat yourself) with regard to the variable names you can use the `:` command inside the script (which just expands its arguments) as in : ${hey:='default one'} or even more briefly just use that `:=` {or `=`} assign if empty or unset {or assign if unset} at the first use case. Also, besides shells most prog.langs have easy ways to receive these { getenv in C, os.environ.get("do_this", "default two") in Python, etc. }. -- I think what people really miss here is the (rarely used, I guess?) shell calling/invocation syntax @cduzz points out of: var1=val1 var2=val2 program which is notably even more terse than GNU long options: program --var1=val1 --var2=val2 Also missing is a documentation standard/convention like: help= program to dump out settings possibilities and their defaults and

Read the rest

maybe their types (integer, string, bool, etc.). One virtue of the `:` syntax above is that it is rare enough in "ordinary shell code" that you could probably auto-generate the help from such a table at the top of the script via grep '^: ' "$0" at least if you are willing to assume the invoker sets $0 to a full path. Soon enough you may outgrow shell programming and, if you become used to such nice conveniences and are willing to learn Nim, I might then recommend something more like https://github.com/c-blake/cligen

In Programs are dead, and JavaScript has killed them

cb321·Nov 11, 2022

I have not found this slower-than-C to be the case. You may need to use something like `iterator getDelims` in https://github.com/c-blake/cligen/blob/master/cligen/osUt.ni... to manage memory with fewer copies/less alloc "more like C", though or perhaps `std/memfiles` memory mapped IO. More pithy ways to put it are that "there are no speed limits" or "Nim responds to optimization effort about as well as other low level languages like C". You can deploy SIMD intrinsics, for example. In my experience, it's not that hard to "pay only for what you use". As a more concrete thing, I have timed (yes, on one CPU, one test case, etc..many caveats) the tokenizer used in https://github.com/c-blake/bu/blob/main/rp.nim to be faster than that used by the Rust xsv. Of course, you really shouldn't tokenize a lot if it's costly/data is big, but rather

Read the rest

save a binary answer that does not need parsing (or perhaps more accurately is natively parsed by the CPU).

In A cost model for Nim

cb321·Nov 11, 2022

Nim gives a bit more choice in many dimensions than many languages -- how to manage memory, whether to use the stdlib at all for things like hash tables, and yes, also syntactic choices like several ways to call a function. This can actually be convenient in constructing a DSL for something with minimal fuss. While `func arg1 arg2` might look weird in "real" "code", it might look great inside some DSL and you can just have it be a "regular Nim invocation" instead of something special to get that. There are also compile-time superpowers like macros that just receive a parsed AST. That can be used to "re-parse" or "re-compile" external code as in https://github.com/c-blake/cligen. So, trade-offs like in all of life. There is even a book called The Paradox Of Choice [1]. I think there is just a spectrum/distribution of human predisposit

Read the rest

ion where some like to have things "standardized & packaged up for them" while others more like to invent their own rules..and enough variation within the population that people have to learn to agree to disagree more. (EDIT: and FWIW, I think this is context-modulated - the same person could be on one end of the spectrum about gardening and the other about software.) I do feel like the syntax is far less chaotic than Perl. [1] https://en.wikipedia.org/wiki/The_Paradox_of_Choice

In A cost model for Nim

cb321·Oct 26, 2022

Re CLIs in Nim..Most find https://github.com/c-blake/cligen easy to use.

In Python 3.11 is faster than 3.8

cb321·Jun 17, 2022

https://github.com/c-blake/cligen can make the CLI integration part pretty frictionless.

In This Month with Nim: April and May 2022

cb321·May 7, 2022

Since `ps` is featuring prominently here, folks might be interested in https://github.com/c-blake/procs which is a color ps (Linux-only right now). It has a more canonical CLI since it is based upon the Nim CLI generator https://github.com/c-blake/cligen. It also uses cligen's subcommand feature (display, find, scrollsys) and so it can replace pgrep, pkill, ps, top, vmstat, etc., etc. Uses the same color scheme as https://github.com/c-blake/lc which re-organizes the mismash ls CLI quite a bit.

In Unix command line conventions over time

cb321·Mar 18, 2022

Nim is a systems programming language [1] just with very decent ergonomics. Interfacing to C/C++ is trivial (just a declaration) and to others (e.g. Rust) is possible. E.g., there is code that interfaces to a custom Linux kernel module for fast file tree walking. [2] { That same github account has several other "systems programming in Nim projects" - low overhead syslogd, color ps/color top, ls, fast symspell/edit distances, a prototype search engine, an alternative to on-disk protobuffers with online random access, etc. There are also a lot over at https://github.com/treeform and surely many others. } You can also export Nim impls to Python easily, though I very much agree Python's time in the sun is over (and I say this having been a user since ~1993). It now seems more a generator of problems/complexity than of simplifying solutions

Read the rest

. Nim can also compile to Javascript letting you do both front- & back-ends in Nim. Science is an almost unbounded fractal set of human investigations. Nim is usable for science (e.g. ask questions here [3]), but the ecosystem is undeniably much smaller than Julia or Python's. (Julia's is much smaller than Python's, and for some things R can be much bigger, actually.) So, a "depends what you need" caveat just has a much stronger "caveat force" here. What "large, multi-dev" needs is honestly harder to say/more subjective/maybe manager-subjective. If it is "cheap, just out of school programmers with which to replace expensive, departing mess-makers", I think Java may have always had more plentiful options than Python. ;-) This is closer to a human-organization-complete kind of concern and almost intrinsically "very dependent upon circumstances/context". I just didn't want to ignore it. At least Stefan Salewski [4] thinks Nim is suitable or teaching people introductory programming, though. [1] https://nim-lang.org/ [2] https://github.com/c-blake/cligen/blob/master/cligen/dents.n... [3] https://app.element.io/#/room/#nim-science:envs.net [4] https://ssalewski.de/nimprogramming.html

In Python 3 Types in the Wild

benhoyt·Feb 3, 2022

rp looks like a very interesting and clever approach. I'll have to take a closer look. Is https://github.com/c-blake/cligen/blob/master/examples/rp.ni... the extent of rp's documentation?

In Optimizing GoAWK with a bytecode compiler and virtual machine

cb321·Feb 3, 2022

Instead of interpreters, if one has less of a "must be a full featured prog.lang" mentality and a fast compiler like Go or Nim [1] (or is willing to wait, for slow optimizing compiles to apply against big data sets) then an end-to-end simpler design for "one-liners" (or similarly simple programs) is the whole program generator. Maybe "big IFs", but also maybe not. To back up my simplicity claim, consider rp [2] -- like 60 non-comment/import/signature lines of code for the generator. Generated programs are even smaller. But, you can deploy gcc or clang or whatever against them and make fast libraries in the host language. Why, if you are willing to write those little generation command options in C99 then you can compile the harness with tcc [3] in about 1 millisecond which is faster than most interpreter start-up times - byte code or o

Read the rest

therwise - and can link against gcc -O3 (or whatever) helper libraries. Anyway, I only write this because in my experience few people realize how much development cost they buy into when then insist on a full featured prog.lang, not to criticize Ben's work. You also make users learn quirks of a new language instead of the quirks of a "harness" which may be fewer|easier. (EDIT: Awk is fairly well established, of course.) [1] https://forum.nim-lang.org/ [2] https://github.com/c-blake/cligen/blob/master/examples/rp.ni... [3] https://repo.or.cz/w/tinycc.git

In Optimizing GoAWK with a bytecode compiler and virtual machine