{
  "id": 18511,
  "title": "An old-new take on argument parsing in Rust",
  "url": "https://urgent.news/2026/08/01/an-old-new-take-on-argument-parsing-in-rust",
  "topic": "culture",
  "section": "Culture",
  "published": "2026-08-01T19:31:15.000Z",
  "source": {
    "name": "Lobsters",
    "slug": "lobsters",
    "url": "https://jmmv.dev/2026/07/hello-getoptsargs.html"
  },
  "original_language": "en",
  "account": "Over the years, the author has written numerous command-line applications across various programming languages. This experience has led to the development of certain opinions about how command-line applications should behave. One of the core beliefs is that consistency is key, and applications should adhere to the ecosystem they are intended for, making them feel \"at home\" within that environment rather than reinventing argument parsing and help presentation.\n\nThe author argues that when developing command-line applications in Go, it is natural to use the built-in flag library for defining flags, which makes the tool feel normal to other Go developers. However, the end user is usually indifferent to the language the tool is written in. This consistency matters to the author, who develops tools for a specific ecosystem, not a particular language. The goal is for these tools to integrate well, regardless of the language they are written in.\n\nThe article focuses on Rust command-line applications, where the assumption is that the clap crate is used to parse options and arguments. While clap provides a nice and powerful declarative interface for defining application interfaces, it often feels out of place in traditional Unix-like programs due to its colorful output and the magic involved with #[derive] libraries. Additionally, clap does not provide enough mechanisms to define an application \"end to end.\"\n\nRust's main function returns an ExitCode, which is sufficient for reporting success or failure to the caller. However, this leaves the control flow in the application's hands. Calling clap within the main function is necessary, but there is no guarantee that it is called at the right time. This can lead to unintended behavior, such as --help not working if config files are malformed or unavailable.\n\nWhile there are other Rust libraries for parsing command lines, such as argh, none of them provide the desired \"small Unix-y framework\" that the author is looking for. This framework should treat options and positional arguments as one interface, validate both consistently, and own the startup sequence from parsing to exit code.\n\nIn response to this need, the author developed their own library called getoptsargs, which builds on and extends the ancient getopts in the tradition of Unix-like systems. getoptsargs is essentially a wrapper over getopts that offers extended argument-parsing facilities.",
  "summary": null,
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}