Creating a CLI: Language Choices
After a lot of my work with gathering JIRA data, I’ve had to go an use the API from PostMan or execute a script more often than now, as opposed to using AI. Even with Claude, Amazon, Rovo, and Gemini — many times will be given a script to execute because the AI’s cannot use my credentials or cannot do a two-step process like gather info, then iterate through that info–> needed arest + code solution.
Decided to give a shot at creating a simple JIRA CLI (apart from Atlassian’s, which requires special permissions) based on these APIs and scripts I’ve been creating.
The first thing I am curious about is what language is best to develop a CLI with. Considerations are easy cross-platform deployability, and less set-up (like needing a special version or a code platform). Also, I intend to vide-code mosst of this and do some conversions so would not like any crazy languages as suggestions.
I asked AI.
“Best” Language to Write a CLI?
Here is a summary that Gemini in GDocs created from Q, Claude, and Gemini results when asked about the “best” code platform to write a CLI:
Best Language for CLI Development
The document recommends Go (Golang) as the top choice for professional, cross-platform CLIs.
- Go (Recommended): The “industry standard” due to its ability to compile to a single static binary, which makes distribution incredibly simple, as the end-user does not need to install a runtime environment (like Python or Node.js).
- Rust: The “performance powerhouse,” ideal for system tools and high-performance applications, also offering excellent distribution via static binaries but with a steeper learning curve.
- Python: The “king of prototyping,” favored for rapid development and automation, despite distribution being more difficult due to the requirement of a Python runtime and managing dependencies.
Languages for Specific CLIs
The document details the languages used by several major CLI tools, which often reflects a balance between the speed of development and ease of distribution:
CLI Tool Primary Language(s) Key Distribution Factor Note on Amazon Q CLI AWS CLI (Amazon’s primary tool) Python V2 is distributed as a self-contained installer that bundles its own Python runtime, giving it a single-file-like feel. The document does not specify Amazon Q CLI, but the highly relevant AWS CLI is Python-based. Claude Code (CLI) TypeScript/Node.js Distributed via NPM or self-contained installers that can bundle Node.js. The latest version of Anthropic’s open-source tool is primarily written this way. Gemini CLI TypeScript/Node.js Distributed via NPM, Homebrew, or npx, requiring Node.js 20+ for installation via NPM.This is based on the open-source google-gemini/gemini-clirepository.KIRO CLI TypeScript/Node.js Leverages the NPM ecosystem for development. This is a third-party AI CLI tool. GitHub CLI Go Follows the industry standard for easy distribution via a single binary. Mentioned as an example of a popular modern CLI written in Go.
Why isn’t TypeScript/Node.js a top choice?
TypeScript/Node.js is not generally considered the top choice for all CLIs (compared to Go or Rust) primarily due to distribution and runtime requirements.
The document highlights the following downsides:
- Requires a Runtime: An end-user must have the Node.js runtime installed on their system to run a standard Node.js/TypeScript CLI, which adds a dependency for the user. Go and Rust, in contrast, compile to a single static binary that runs directly without needing an interpreter or runtime.
- Perceived “Heaviness”: The necessary Node.js dependencies, often contained in a large
node_modulesfolder, can make the tool feel “heavy” compared to a self-contained Go or Rust binary.- Larger Memory Footprint: The Node.js runtime environment generally has a larger memory footprint than a native executable.
Despite these drawbacks, the language is still an excellent choice for specific use cases, such as:
- Tools for the web development ecosystem.
- Projects that need to leverage the massive NPM ecosystem and existing JavaScript/TypeScript tooling.
- Tools where the development team is already familiar with JavaScript/TypeScript.
In modern distributions (like AWS CLI v2 or the Claude Code CLI), this downside is sometimes mitigated by shipping the CLI with an embedded runtime so the end-user doesn’t have to install Node.js separately.
DevOps vs Developer CLI:
Language Platforms Differ
So do devops CLIs tend to be written in GO, and application developer CLIs tend to be not written with Go?
That is a very accurate observation of the current landscape. There is a strong “language divide” between tools built to manage infrastructure (DevOps) and tools built for application developers.
The primary reason for this split isn’t just aesthetic; it’s about distribution constraints versus ecosystem integration.
1. DevOps CLIs: The Reign of Go
If you look at the heavy hitters in DevOps—Docker, Kubernetes, Terraform, Helm, and the GitHub CLI—they are almost all written in Go.
The Problem: DevOps tools often need to run on “clean” servers, inside bare-bones Docker containers, or on a colleague’s machine that doesn’t have any specific software installed.
The Go Solution: Go compiles to a statically linked binary. This means the executable contains every single piece of code it needs to run.
The Result: You can just
curla binary and run it. No “You need Python 3.9,” no “Your Node version is too old,” and nopip installerrors. For someone managing a server, this reliability is non-negotiable.Core DevOps Stack (Go-Dominant)
Docker: (Go)
Kubernetes (kubectl): (Go)
Terraform: (Go)
Prometheus: (Go)
GitHub CLI (
gh): (Go)2. Developer CLIs: The NPM & Python World
When a CLI is meant for Application Developers (especially Web or AI developers), the language choice usually shifts to TypeScript (Node.js) or Python.
The Reason: These tools live where the developers already spend their time.
Ecosystem Symbiosis: If you are a frontend dev, you already have Node installed. If you are an AI researcher, you already have Python. Forcing these users to learn Go just to contribute to a CLI’s codebase would create a “contribution tax.”
Rich UI Libraries: TypeScript has libraries like Ink (which lets you build CLI layouts using React components), making it much easier to build the highly interactive, colorful UIs that modern app devs expect (like the Gemini or Claude CLIs).
Developer Tooling Stack (Node/Python Dominant)
Vercel / Netlify CLIs: (TypeScript/Node)
Claude Code: (TypeScript/Node)
AWS CLI: (Python)
Gemini CLI: (TypeScript)
Firebase CLI: (TypeScript/Node)
Summary: Go vs. The Rest
The “Hybrid” Exception
You will occasionally see a shift toward Rust for both groups (like the Bun runtime or Oxc). Rust offers the “single binary” benefit of Go but with even higher performance and better safety. It is currently the “cool” choice for developers who want the portability of a DevOps tool but the high-end UX of an app-dev tool.
Direction
Finally, for my purposes — writing a quick JIRA CLI, asking Gemini for a recommendation considering my bulk-operation need:
Language Comparison for a Bulk JIRA CLI
| Language | Strengths (For JIRA CLI) | Weaknesses (For Bulk Operations/Distribution) |
|---|---|---|
| Go (Golang) | Superior for Bulk Operations (Goroutines for parallel API calls); Excellent Distribution (Single static binary). | Terminal UI/TUI libraries may be less mature than Node.js’s; Less native JSON handling than TypeScript. |
| Python | Rapid development, familiar for data handling. | Not ideal for high-speed parallel API calls (Global Interpreter Lock); Difficult Distribution (Requires Python runtime/dependencies). |
| TypeScript/Node.js | Excellent for highly interactive CLIs (TUIs); Easy to implement concurrency (Promise.all). |
“Cold Start” overhead; Distribution headache (Requires Node.js runtime), Slower for high-CPU data manipulation. |
The Verdict: Choose Go if you want a fast, portable utility that feels like a native system command and can handle massive bulk operations. Choose TypeScript if your priority is building a highly interactive, menu-driven tool.