Go run

Artículo original ↗ Discusión en Hacker News ↗

El comando `go run` de Go se presenta como un ejemplo de cómo unas herramientas simples pueden hacer que un lenguaje compilado se sienta casi como si fuera un script, especialmente con convenciones como `go run .` y la descarga automática de dependencias. Los comentarios contrastan esto con los ecosistemas de JavaScript/TypeScript, donde múltiples runtimes, sistemas de módulos y gestores de paquetes pueden hacer que tareas básicas parezcan más complejas, aunque herramientas más nuevas como Deno y Bun intentan cerrar esa brecha. El intercambio destaca concesiones más amplias entre simplicidad y flexibilidad en el diseño del lenguaje, el manejo de errores, los sistemas de compilación y la gestión de dependencias.

Uso y convenciones de go run

  • Muchos señalan que go run main.go deja de funcionar en cuanto main se تقسیم across files; go run . ejecuta el paquete actual y funciona con múltiples archivos y subdirectorios (go run ./cmd/foo).
  • Varios se quejan de que los tutoriales enfatizan go run file.go en lugar del más simple y escalable go run ..
  • Algunos desearían que go run sin argumentos detectara automáticamente un paquete main, como otros subcomandos de go, pero otros argumentan que eso sería ambiguo con múltiples binarios cmd/*.
  • Los módulos añaden fricción: a menudo hay que estar en la raíz del módulo para hacer go run ., o usar -C para cambiar de directorio.

Simplicidad, convenciones y curva de aprendizaje

  • Go recibe elogios por su disposición predecible: directorios como paquetes, cmd/ para binarios; navegar bases de código desconocidas suele ser sencillo.
  • Otros encuentran poco intuitivo el límite entre “simple” y “complejo” (por ejemplo, saber cuándo usar go run . frente a go run path/to/main.go).
  • Hay debate sobre cuánto deberían influir las expectativas de lenguajes previos en los tutoriales de Go y en los modelos mentales.

Comparación con JS/TS y otros ecosistemas

  • Algunos comparan go run con el ecosistema de Node/TypeScript, citando fragmentación (npm, yarn, pnpm; CommonJS vs ESM; transpilación de TS, configuración de Jest/Babel).
  • Otros responden que Node ya puede ejecutar ESM (.mjs), TS mediante herramientas sencillas (tsc, loaders), y que herramientas más recientes (Deno, Bun, tsx, npx) hacen que programar en TS sea igual de fácil.
  • Se menciona Rust con cargo run, herramientas de Python (Poetry), Nix y Bazel como flujos análogos de “compilar + ejecutar”.

Obtención de dependencias y seguridad

  • Una característica destacada: go run descarga automáticamente dependencias desde rutas de módulos.
  • A quienes lo apoyan les gusta el flujo de trabajo de baja fricción, y argumentan que las versiones quedan fijadas por go.mod/go.sum y respaldadas por el proxy de Go.
  • Los críticos ven la descarga automática durante run como un antipatrón de seguridad/operaciones y prefieren pasos explícitos de “obtener y luego ejecutar”, especialmente para descargas por primera vez.

Visiones más amplias sobre Go

  • Muchos elogian las herramientas de Go (una sola toolchain, binarios estáticos, compilación cruzada, despliegue simple; a veces incluso sin necesidad de Docker).
  • Otros critican la verbosidad en el manejo de errores de Go y la falta de características avanzadas de tipos en comparación con Rust o TypeScript, aunque algunos aprecian su explicitud.
  • Go se ve como un punto intermedio entre Rust de bajo nivel y TS de alto nivel, adecuado para servicios backend y pequeñas utilidades, pero no satisfactorio para todos los gustos de lenguaje.