Los scripts deberían escribirse usando el lenguaje principal del proyecto

Postura general sobre “scripts en el lenguaje principal”

• La discusión se divide entre “está bien cuando encaja” y “es una generalización peligrosa”.
• Muchos insisten en que depende mucho del lenguaje, el tipo de proyecto, el contexto de despliegue y las habilidades del equipo.
• Algunos ven el artículo como más moderado de lo que sugiere el título; otros siguen viendo la idea como un enfoque de martillo y clavo.

Argumentos a favor de usar el lenguaje principal

• Un lenguaje compartido reduce el cambio de contexto y puede reutilizar la lógica de dominio y las APIs.
• Es más fácil migrar después scripts ad hoc a trabajos programados o herramientas de producción.
• Para algunos lenguajes (Go, Kotlin, C#, JVM en general), el soporte para scripting o herramientas rápidas de run hacen esto práctico.
• Los binarios de un solo lenguaje (en especial Go) simplifican la distribución multiplataforma y evitan los dolores de cabeza de dependencias al estilo Python.

Argumentos en contra / “usa la herramienta adecuada”

• Muchos lenguajes (C, C++, Rust, Java con toolchains completos) son malas opciones para automatizar rápidamente el sistema de archivos o el sistema operativo.
• Para infraestructura y despliegue, herramientas especializadas (Ansible, Fabric, Terraform, Nix, Docker/Compose, Helm, etc.) suelen superar al “código de despliegue” hecho a medida en el lenguaje de la app.
• Incrustar la lógica de despliegue en el binario principal puede difuminar responsabilidades, convertirse en un frágil sistema DevOps personalizado y dejar fuera a expertos que no conocen el lenguaje.
• Los scripts suelen ser investigaciones de una sola vez; usar un lenguaje/cadena de herramientas pesada es excesivo.

Shell frente a scripting de mayor nivel

• Los defensores de bash/sh destacan su ubicuidad, la integración estrecha con herramientas del sistema operativo y su simplicidad para scripts pequeños.
• Otros subrayan las trampas de bash, las reglas de comillas, los problemas de portabilidad (macOS frente a Linux, utilidades no GNU) y los fallos de “funciona en mi máquina”.
• Herramientas como shellcheck mitigan algunos riesgos del shell; las guías de estilo sugieren reescribir shell largo o complejo en un lenguaje estructurado.

Experiencias específicas por ecosistema

• Se elogia a Go como un excelente lenguaje para “scripting” mediante pequeños CLI o go run, especialmente para entornos de desarrollo heterogéneos.
• El scripting en Kotlin y los shells personalizados muestran que un lenguaje principal tipado puede ofrecer una experiencia de scripting agradable.
• Los ejemplos con C++ y Rust muestran dolor: recompilaciones pesadas, binarios específicos de plataforma y dependencia casi universal de lenguajes de scripting externos (a menudo Python).

Equipo, mantenibilidad y aprendizaje

• Los lenguajes extra añaden coste de incorporación, pruebas y herramientas, pero muchos sostienen que los ingenieros deberían manejar un par de lenguajes de scripting comunes.
• Los scripts demasiado complejos y no probados son un problema mayor que la elección del lenguaje; los comentarios enfatizan pruebas, documentación, supuestos claros y separación de responsabilidades.
• Los LLM reducen un poco la barrera para trabajar en lenguajes desconocidos, pero no lo suficiente como para eliminar los problemas semánticos y de seguridad.