Go vs Rust CLI Tools: Performance and DX Guide [2026]

Go and Rust both ship excellent first-party tooling, but they optimize for different kinds of CLI work. As of April 29, 2026, the current Go stable line is 1.26.2, while Rust stable release notes list 1.93.1. In this tutorial, you’ll build the same tiny greeting CLI in both languages, verify the output, then compare binary size, build speed, startup behavior, and day-to-day developer experience.

Prerequisites and Setup

1. Install or verify both toolchains

1. Check Go:

   go version

2. Install Rust with the official bootstrapper if needed:

   curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

3. Check Rust and Cargo:

   rustc --version
   cargo --version

The official Go docs use go mod init, go build, and go install for module and binary workflows. The Cargo book uses cargo new and cargo run as the standard Rust entry point.

Step 1: Build the Go CLI

2. Create a minimal Go command

1. Create the project:

   mkdir greet-go
   cd greet-go
   go mod init example/greet-go

2. Add main.go:

   package main
   
   import (
       "flag"
       "fmt"
   )
   
   func main() {
       name := flag.String("name", "world", "name to greet")
       count := flag.Int("count", 1, "number of greetings")
       flag.Parse()
   
       for i := 0; i < *count; i++ {
           fmt.Printf("Hello, %s!\n", *name)
       }
   }

3. Run it without producing a binary:

   go run . --name Taylor --count 2

4. Build the executable:

   go build -o greet-go

This is classic Go DX: almost no ceremony, fast feedback, and a standard library parser that is enough for many internal tools. The tradeoff is that the stdlib gives you less help for richer validation, shell completions, or nested subcommands.

Step 2: Build the Rust CLI

3. Create the same tool in Rust

1. Create the package with Cargo. The current docs show edition 2024 as the default:

   cargo new greet-rs
   cd greet-rs

2. Add clap with the derive feature:

   cargo add clap --features derive

3. Replace src/main.rs:

   use clap::Parser;
   
   #[derive(Parser, Debug)]
   #[command(version, about, long_about = None)]
   struct Args {
       #[arg(short, long, default_value = "world")]
       name: String,
   
       #[arg(short, long, default_value_t = 1)]
       count: u8,
   }
   
   fn main() {
       let args = Args::parse();
   
       for _ in 0..args.count {
           println!("Hello, {}!", args.name);
       }
   }

4. Run it in development:

   cargo run -- --name Taylor --count 2

5. Build an optimized binary for fair comparison:

   cargo build --release

Rust’s parser story is the opposite of Go’s. You write a bit more syntax up front, but clap gives you stronger defaults for help output, flag metadata, type-aware parsing, and future subcommand growth. That pays off fast once your CLI stops being a one-file script replacement.

Step 3: Compare Performance and DX

4. Measure what matters

For CLI tools, the useful metrics are rarely peak throughput alone. Measure the things users and maintainers actually feel:

• Build speed: how quickly you can iterate during development.
• Startup time: how fast the command responds to a single invocation.
• Binary size: relevant for containers, CI agents, and edge devices.
• Parser maintenance cost: how painful it is to add flags, validation, and subcommands six months later.

# Go
cd greet-go
time ./greet-go --name Taylor --count 100
ls -lh ./greet-go

# Rust
cd ../greet-rs
time ./target/release/greet-rs --name Taylor --count 100
ls -lh ./target/release/greet-rs

In many teams, the practical result looks like this:

• Go usually wins the shortest edit-build-run loop.
• Rust often rewards release builds with a stronger optimization ceiling.
• Go’s stdlib keeps tiny tools tiny.
• Rust with clap becomes easier to extend once your interface surface expands.

When to choose each

Choose Go when:

• You need an internal ops tool this afternoon, not a framework decision.
• Your CLI is mostly one command plus a handful of flags.
• Fast incremental builds matter more than advanced parser features.
• Your team already has deep Go operational experience.

Choose Rust when:

• You expect the CLI to grow into subcommands, validation, and richer UX.
• Compile-time safety and explicit types are worth the extra verbosity.
• You care about squeezing more out of optimized builds.
• You want stronger guarantees before shipping binaries broadly.

If you publish snippets in docs, READMEs, or internal runbooks, clean them up with TechBytes’ Code Formatter so your examples stay copy-paste friendly.

Verification, Troubleshooting, and What's Next

Expected output

Both binaries should produce the same result:

./greet-go --name Taylor --count 2
Hello, Taylor!
Hello, Taylor!

./target/release/greet-rs --name Taylor --count 2
Hello, Taylor!
Hello, Taylor!

You should also see helpful autogenerated usage from both tools when you pass --help. Rust’s help output will generally be richer by default because clap derives it from the struct and attributes.

Troubleshooting top 3

• Rust feels slow: you are probably testing a debug build. Re-run with cargo build --release and execute the binary from target/release.
• Go binary is not found after install: the Go docs note that your install path must be on PATH, or you should set GOBIN explicitly.
• Flags do not parse as expected: in Rust, make sure you used cargo run -- --name Taylor with the extra separator. In Go, confirm you called flag.Parse().

What's next

• Add a subcommand such as version or completion and compare the code growth in both languages.
• Introduce config-file loading and environment variable support to see where ecosystem tooling changes the DX story.
• Run a real benchmark in CI on cold starts and binary size before standardizing on one language for your team.