Go es un lenguaje ideal para la ingeniería de software asistida por IA

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

Se está promocionando Go como un lenguaje “ideal” para la ingeniería de software asistida por IA debido a su sintaxis simple, su sólida biblioteca estándar, sus compilaciones rápidas y su tooling altamente opinado, que facilitan que los modelos grandes generen y formateen código coherente. Muchos programadores coinciden en que estos rasgos funcionan bien con agentes de programación, pero otros sostienen que lenguajes más estrictos y expresivos como Rust, TypeScript o Elixir son más adecuados porque ofrecen garantías estáticas más fuertes y una concurrencia más segura, algo crítico cuando los humanos revisan menos y la IA escribe más. En todos los lenguajes, la gente destaca compensaciones entre la dureza y la velocidad del compilador, la verbosidad y los límites de la ventana de contexto, y la madurez del ecosistema y la cobertura de datos de entrenamiento al elegir qué emparejar con los LLM.

Fortalezas percibidas de Go para el desarrollo asistido por IA

  • Lenguaje simple, pequeño y estable, con pocas características y convenciones fuertes. La mayor parte del código Go se parece entre sí, lo que ayuda a los LLM a generarlo y refactorizarlo de forma predecible.
  • Excelente biblioteca estándar y herramientas: gofmt, go test/coverage, linters, go fix, manejo sencillo de módulos y herramientas especializadas (por ejemplo, prohibir el acceso a archivos, imponer comprobaciones de errores).
  • La compilación incremental rápida proporciona ciclos de retroalimentación ajustados cuando los agentes compilan, ejecutan y prueban repetidamente.
  • El tipado estático y el GC ofrecen una seguridad y un rendimiento “suficientemente buenos” para el uso típico en web/backend sin una gestión compleja del ciclo de vida.
  • La gran base de código existente y las APIs estables significan que los modelos han visto mucho Go idiomático.
  • El despliegue sencillo (un solo binario estático) y la idoneidad para CLIs y servicios backend lo convierten en una opción predeterminada atractiva cuando los humanos se dedican principalmente a orquestar agentes.

Críticas y escepticismo sobre Go como “ideal”

  • Muchos ven el artículo como marketing o “generative engine optimization” más que como investigación respaldada por datos; las anécdotas internas no son evidencia sistemática.
  • Go se describe como verboso y cargado de boilerplate (if err != nil por todas partes, sin tipos de datos algebraicos), lo que hace más difícil la revisión humana de grandes diffs generados por IA.
  • El sistema de tipos se considera básico: soporte débil para invariantes, problemas con nil, interfaces estructurales que son más difíciles de rastrear para herramientas/LLMs.
  • El modelo de concurrencia es potente pero fácil de usar mal; referencias al estudio de Uber y a implementaciones defectuosas de Raft sugieren que el código Go puede tener más errores de concurrencia, y se informa que los LLM tienen dificultades con Go concurrente no trivial.
  • Las herramientas de linting y análisis estático pueden ser lentas en bases de código grandes; algunas barreras de seguridad (por ejemplo, disciplina de errores, seguridad frente a nil) requieren herramientas y convenciones adicionales.

Rust, TypeScript y otros contendientes

  • Los defensores de Rust argumentan que su compilador estricto y su rico sistema de tipos son ideales como barreras para los LLM: se detectan más errores en tiempo de compilación, la concurrencia es más segura y el código es más denso y expresivo.
  • Contrapunto: la compilación lenta y la fricción del borrow checker pueden costar tokens y tiempo cuando los agentes iteran; algunos LLM “escapan” usando unsafe o clonando en exceso.
  • Se cita TypeScript y C# como opciones sólidas para aplicaciones orientadas al usuario o de tipo CRUD, con herramientas ricas y sistemas de tipos, aunque la complejidad del ecosistema de JS/TS es un inconveniente.
  • Se menciona que Elixir/Gleam son sorprendentemente fuertes en algunos benchmarks de LLM; Python se usa mucho, pero a menudo produce código generado por IA desordenado.
  • Varios comentaristas insisten en que no existe un único lenguaje “ideal”: la elección debe depender del dominio, del ecosistema y de cuánto se confíe en comprobaciones en tiempo de compilación frente a comprobaciones en tiempo de ejecución y basadas en pruebas.