Go es la elección preferida para la infraestructura moderna —herramientas como kubectl, terraform o hugo lo demuestran— porque sus binarios son estáticos por naturaleza. Esto significa que el compilador empaqueta todo lo necesario para ejecutar el programa en un único archivo ejecutable, sin depender de una versión específica de Python, Node.js o una JVM instalada en el sistema del usuario. Cuando ejecutas una herramienta escrita en Go, el sistema operativo solo necesita cargar el binario y empezar; no hay una fase de resolución de dependencias ni un intérprete que cargar, lo que resulta en un tiempo de arranque casi instantáneo (típicamente en el orden de los milisegundos).
Esta arquitectura resuelve el problema del “runtime mismatch” de raíz: no tienes que preocuparte por si el usuario tiene la versión correcta de la librería requests o si su entorno de Node tiene conflictos de node_modules. Además, la compilación cruzada es una característica nativa del compilador; con simplemente cambiar dos variables de entorno (GOOS y GOARCH), puedes generar un binario para Windows, Linux (amd64 o ARM64) o macOS desde tu máquina de desarrollo en segundos.
Sin embargo, no todo es el binario. La elección de la librería para manejar argumentos es crucial. Si tu herramienta es sencilla, el paquete flag de la biblioteca estándar es suficiente y mantiene el binario ligero. Pero si estás construyendo una CLI compleja con subcomandos anidados, autocompletado de shell y sugerencias de comandos mal escritos, te encontrarás con que el estándar de facto es cobra [disponible desde el inicio]. cobra es la base de casi toda la infraestructura de Kubernetes, permitiendo una estructura jerárquica que el paquete flag no gestiona de forma nativa sin mucho código repetitivo.
Si intentas construir una herramienta compleja usando solo flag de forma desordenada, terminarás con un código lleno de condicionales anidados para manejar subcomandos y un sistema de ayuda (help) inconsistente que frustrará a tus usuarios. Por el contrario, si usas un framework pesado para una herramienta de un solo propósito, estarás añadiendo complejidad innecesaria a una lógica que debería ser lineal.
package main
import (
"flag"
"fmt"
"os"
)
// Esta estructura representa la lógica de nuestra CLI de gestión de servidores.
// Implementamos subcomandos manualmente para entender qué hace 'cobra' por debajo.
func main() {
if len(os.Args) < 2 {
printUsage()
os.Exit(1)
}
// El primer argumento (después del comando) es nuestro subcomando.
command := os.Args[1]
switch command {
case "start":
handleStart(os.Args[2:])
case "stop":
handleStop(os.Args[2:])
case "status":
handleStatus(os.Args[2:])
case "help":
printUsage()
default:
fmt.Printf("Comando desconocido: %s\n", command)
printUsage()
os.Exit(1)
}
}
func handleStart(args []string) {
// NewFlagSet crea un conjunto de flags aislado para este subcomando específico.
// Esto es lo que evita que los flags de 'start' colisionen con los de 'stop'.
startCmd := flag.NewFlagSet("start", flag.ExitOnError)
// Definimos un flag con valor por defecto.
timeout := startCmd.Int("timeout", 30, "Tiempo de espera en segundos")
force := startCmd.Bool("force", false, "Forzar el inicio inmediato")
// Parseamos solo los argumentos que pertenecen a este subcomando.
if err := startCmd.Parse(args); err != nil {
fmt.Printf("Error en comando start: %v\n", err)
return
}
fmt.Printf("🚀 Iniciando servidor... (timeout: %ds, force: %v)\n", *timeout, *force)
}
func handleStop(args []string) {
stopCmd := flag.NewFlagSet("stop", flag.ExitOnError)
id := stopCmd.String("id", "", "ID del proceso a detener")
if err := stopCmd.Parse(args); err != nil {
return
}
if *id == "" {
fmt.Println("❌ Error: Debes proporcionar un --id para detener el proceso.")
stopCmd.Usage()
os.Exit(1)
}
fmt.Printf("🛑 Deteniendo proceso %s...\n", *id)
}
func handleStatus(args []string) {
fmt.Println("📊 Estado actual: Todos los servicios están operativos.")
}
func printUsage() {
fmt.Println("Uso: server-cli <comando> [argumentos]")
fmt.Println("\nComandos:")
fmt.Println(" start Inicia un nuevo servidor")
fmt.Println(" stop Detiene un servidor existente")
fmt.Println(" status Muestra el estado actual")
}
Desglose del ejemplo
Para implementar subcomandos de forma profesional sin librerías externas, el código utiliza flag.NewFlagSet en lugar de usar el paquete flag global. Si usaras flag.String(...) directamente en el main, estarías definiendo flags que pertenecen a toda la aplicación, lo que te impediría tener un --id que solo funcione en stop y no en start.
En handleStart, creamos un nuevo FlagSet. Esto encapsula la lógica de parsing. Cuando ejecutamos server-cli start --timeout 60, el slice os.Args[2:] contiene únicamente --timeout 60. El método startCmd.Parse(args) procesa esos argumentos de forma aislada. Esto es fundamental para la escalabilidad: cada subcomando tiene su propio espacio de nombres de flags y su propia lógica de ayuda (Usage).
El flujo de control en main actúa como un enrutador. Primero verificamos la longitud de os.Args para evitar un panic por índice fuera de rango y luego usamos un switch para delegar la ejecución. Esta estructura es la que implementan frameworks como cobra de forma mucho más sofisticada, permitiendo incluso subcomandos dentro de subcomandos (ej. server-cli config set key value).
El error frecuente
Un error clásico al construir CLIs en Go es llamar a flag.Parse() al principio del main.
// ERROR COMÚN
func main() {
flag.String("id", "", "ID")
flag.Parse() // <--- Esto consume todos los argumentos
// Si el usuario ejecuta: mi-cli stop --id 123
// flag.Parse() verá "stop" como un argumento posicional y dejará de
// buscar flags, dejando los flags de 'stop' sin procesar o causando errores.
}
Si utilizas subcomandos, nunca uses flag.Parse() global antes de haber identificado qué subcomando ejecutará el usuario. Siempre usa flag.NewFlagSet para cada comando y llama a su respectivo .Parse() solo después de haber identificado el comando deseado.
N° 204