Rust se consolida como el lenguaje predeterminado para las nuevas herramientas CLI
Rust se ha convertido en la opción predeterminada para las nuevas herramientas CLI lanzadas en 2026, desplazando silenciosamente a Go, Python y C en una categoría donde Go había dominado desde mediados de la década de 2010. Ripgrep, fd, bat, exa/eza, delta y decenas de utilidades CLI más recientes están escritas en Rust —y cuando un equipo inicia hoy un nuevo proyecto CLI, Rust es cada vez más el primer lenguaje que se considera, en lugar de una alternativa de nicho.
Esto no es una historia sobre ciclos de hype. Es una historia sobre un conjunto específico de compensaciones —latencia de arranque, seguridad de memoria y distribución en binario único— que resultan importar enormemente para las herramientas de línea de comandos y mucho menos para los servicios web donde Go sigue dominando.
Por qué las herramientas CLI favorecen específicamente a Rust
Una herramienta CLI es invocada miles de veces al día por un solo desarrollador, frecuentemente en bucles ajustados (piénsese en un linter que se ejecuta en cada guardado de archivo, o una herramienta de búsqueda canalizada a través de un script de shell). La latencia de arranque se acumula a esa frecuencia de una manera que no ocurre con un servidor web de larga duración. Rust compila a código nativo sin runtime ni recolector de basura, por lo que una herramienta CLI en Rust arranca en milisegundos de un solo dígito —las herramientas de Go también arrancan rápido, pero pagan un pequeño impuesto de inicialización del GC y del runtime que Rust no tiene.
La seguridad de memoria sin recolección de basura es el segundo factor. Las herramientas CLI procesan con frecuencia entradas no confiables —rutas de archivos arbitrarias, archivos de configuración malformados, argumentos de línea de comandos adversariales. El modelo de ownership de Rust captura clases enteras de errores de memoria en tiempo de compilación, algo que importa más para herramientas que reciben bytes sin procesar de internet (piénsese en un formateador JSON que acepta respuestas de API) que para, digamos, un microservicio interno con una forma de entrada conocida.
Los binarios únicos superan a las dependencias de runtime
La historia de distribución práctica es posiblemente más importante que la historia de rendimiento. Una herramienta CLI en Rust compila a un único binario estático con cero dependencias de runtime —sin versión de intérprete de Python que coincidir, sin Node.js que instalar, sin pip install que falle en un sistema operativo diferente. cargo install o un binario descargado simplemente funciona. Para herramientas distribuidas a miles de desarrolladores con entornos heterogéneos, eso elimina toda una categoría de tickets de soporte.
Las herramientas de Python, en cambio, fallan habitualmente entre entornos de Python 3.9 y 3.11, conflictos de dependencias y confusión con entornos virtuales —una fricción que importa enormemente para una herramienta que debería estar a tan solo un brew install de dos segundos de funcionar.
El precio de la curva de aprendizaje
Nada de esto significa que Rust sea gratuito. El borrow checker tiene una curva de aprendizaje real, y la velocidad de iteración de un desarrollador en solitario que prototipa una herramienta rápida es más lenta en Rust que en Python o incluso en Go, al menos inicialmente. Los equipos reportan que una herramienta CLI en Rust tarda notablemente más en alcanzar una primera versión funcional que la misma herramienta en Go —pero la carga de mantenimiento se invierte con el tiempo, ya que Rust detecta en tiempo de compilación errores que Go y Python solo mostrarían en tiempo de ejecución, a menudo en la terminal de un usuario en lugar de en un conjunto de pruebas.
El ecosistema también ha madurado lo suficiente como para que la curva de aprendizaje sea menos severa que hace cinco años. Crates como clap (análisis de argumentos), serde (serialización) y anyhow/thiserror (manejo de errores) ahora cubren el mismo terreno que en 2020 requería código repetitivo personalizado, lo que significa que un desarrollador competente de Rust puede estructurar una herramienta CLI completa en una tarde.
Lo que esto significa para los equipos que eligen un stack
Si estás construyendo una herramienta CLI interna que otros desarrolladores ejecutarán miles de veces al día, las ventajas de Rust en latencia de arranque y binario único son ahora suficientemente grandes como para justificar la mayor curva de aprendizaje inicial —especialmente porque crates como clap y serde han cerrado la mayor parte de la brecha de productividad con Python. Si tu herramienta es un script puntual que se ejecuta unas pocas veces, o si tu equipo no tiene experiencia en Rust y tienes un plazo ajustado, Python o Go siguen siendo el camino pragmáticamente más rápido —no reescribas en Rust solo porque está de moda. Y si ya mantienes una herramienta CLI en Python que ha superado su caso de uso —arranque lento, cadena de dependencias frágil, usuarios que se quejan de la fricción de instalación— esa es la señal específica que merece tratarse como desencadenante de una reescritura, no la preferencia general por un lenguaje.