Las mentiras que nos decimos para seguir usando Golang (2022)

• El autor es un ornitorrinco

  • Descartar al autor como incompetente para ignorar las críticas es una forma perezosa de actuar.
  • Los desarrolladores junior pueden ver los problemas con una perspectiva nueva, y esa es una razón importante para contratarlos.
  • El autor no es un desarrollador junior y, a través de experiencias diversas, tiene una comprensión del diseño de lenguajes.

• Si mi mamá fuma, entonces debe estar bien

  • Seguir sin más las tecnologías que usan otras empresas es ineficiente.
  • Los blogs técnicos tienen el propósito de hacer que la imagen de la empresa se vea mejor.
  • El blog de Tailscale es honesto, pero hace falta mucho esfuerzo para resolver los problemas de Go.

• Las partes buenas

  • Go tiene un runtime asíncrono y un recolector de basura sobresalientes.
  • Herramientas como la gestión de paquetes, el refactoring y la compilación cruzada son fáciles de usar.
  • Sin embargo, los defectos de Go no pueden ignorarse, y el problema es que el diseño del lenguaje se dio de forma accidental.

• Go es una isla

  • Go tiene poca interoperabilidad con otros lenguajes.
  • Su toolchain es particular, y no se pueden usar ensambladores o depuradores ya existentes.
  • La forma más fácil de integrarlo es a través de fronteras de red.

• Todo o nada (así que no hacemos nada)

  • Go puede dejar campos de estructuras sin inicializar.
  • Pensar que el valor cero siempre tiene significado es una idea ingenua, y en muchos casos causa problemas.
  • La cultura de Go tiende a decirte que tengas cuidado, en lugar de resolver el problema.

• "Rust es perfecto y ustedes son todos unos idiotas"

  • Rust puede adoptarse de manera gradual y se integra bien con otros lenguajes.
  • Parte del éxito de Rust está en que permite migrar hacia un lenguaje seguro.
  • Rust también tiene problemas, pero se están resolviendo gradualmente.

• Usar Go como lenguaje de prototipos / de arranque

  • Se considera que Go es un lenguaje fácil de aprender, pero en realidad requiere mucha experiencia.
  • Le faltan funciones que indiquen con claridad que el código está mal.
  • Las desventajas de Go se hacen visibles con el tiempo, y no es un lenguaje del que sea fácil salir.

• Las mentiras sobre por qué seguimos usando Golang

  • Si otras personas lo usan, entonces también debe servirnos a nosotros
  • Considerar aceptables, individual o colectivamente, los defectos del diseño del lenguaje
  • Pensar que, si tenemos cuidado, podremos superar los problemas
  • Pensar que, como es fácil de escribir, desarrollar software de producción también será fácil
  • Pensar que, como el lenguaje es simple, todo es simple
  • Pensar que siempre podremos reescribirlo más adelante

[tsboard]

Aunque apenas llevo un instante, casi fugaz, metido de lleno en Go, no sé si me corresponde dejar una opinión, pero... Go tiene ventajas y desventajas muy claras, así que tanto quienes lo eligen como quienes lo evitan parecen tener razones bastante definidas. Personalmente, no creo que haya que compararlo con Rust; me parece más correcto compararlo con Kotlin (Java).

Las goroutines de Go son realmente excelentes, pero no son magia. Sobre todo en backend, en proyectos pequeños que usan solo un MySQL, esta concurrencia puede ser bastante difícil de gestionar. Cosas como el agotamiento de recursos de MySQL o la gestión del pool, que en un runtime de JS/TS no suelen requerir tanta atención, resultan más complicadas de lo que parece. Al final, en esta situación la base de datos se vuelve el cuello de botella, así que parte de la ventaja de Go en concurrencia se diluye. (El I/O asíncrono o el event loop de un runtime JS/TS podrían incluso ser más adecuados). Se nota enseguida si pruebas con una herramienta como hey y le metes -c 100.

Y aunque tiene un GC excelente, eso no significa que puedas pasarte punteros a objetos a la ligera y desentenderte de lo que pasa después. Todo tiene trade-offs, pero en Go también conviene, si es posible, pasar los objetos pequeños por copia de valor para que se procesen de inmediato al terminar la función. Tal vez estoy atrapado en una forma de pensar anticuada, pero no debería abordar los punteros con tanta facilidad desde una perspectiva de eficiencia, como haría en C/C++.

Tener que devolver error casi cada vez que una función retorna, y revisar cada vez con if err != nil {} es realmente molesto, pero esto es una ventaja. Sale más barato que try catch. Y la palabra clave defer, que cumple un papel parecido al de finally {}, también es excelente. Está bueno no tener que preocuparse por el momento exacto de liberar recursos. También me gusta que con solo la biblioteca estándar puedas armar de inmediato un muy buen servidor backend (1.23 o superior). Y, sobre todo, lo mejor es que si compilas para el OS de destino, no necesitas otro runtime ni instalaciones previas.

No llevo tanto tiempo usando Go, pero siento que ya me extendí demasiado con una opinión tan personal, así que lo dejo acá jaja. ¡A mí me gusta Go, y también me gustan otros lenguajes!

[GN⁺]

Opiniones de Hacker News

• Hay muchas críticas sobre las desventajas de Go, pero el manejo explícito de errores no es una de ellas. El manejo de excepciones añade una capa de "magia" en la que es demasiado fácil equivocarse. Para proyectos personales prefiero Rust, pero en proyectos grandes donde participa gente con distintos niveles de experiencia, la filosofía de Go es el enfoque de manejo de errores más razonable en el mundo moderno.

  • Go se adopta más que otros lenguajes "nuevos" gracias a su simplicidad. No es el mejor lenguaje, pero por muchas opiniones integradas, suele ser la mejor opción como lenguaje de propósito general.

• Rust y Go son muy diferentes, y ese punto medio que la gente quiere actualmente no existe.

  • Hace falta un lenguaje relativamente simple con un sistema de tipos parecido al de Rust.
  • Gleam y Kotlin se parecen un poco, pero no del todo. Rust es demasiado complejo, así que resulta difícil para quienes no vienen del área o no son especialistas.
  • No existe un lenguaje perfecto, pero Go y Rust han aportado cosas sorprendentes. Ojalá se cree un lenguaje de programación simple y ampliamente disponible inspirado en ambos.

• Me gustan los lenguajes simples. Como la tecnología siempre implica trade-offs, es importante hacer críticas equilibradas.

  • Comparte un enlace a un blog sobre por qué eligió Go.

• Me pregunto por qué es tan importante criticar un lenguaje. La crítica no está escrita de forma constructiva.

  • Todos los lenguajes pueden ser criticados. Go funciona muy bien en proyectos a pesar de sus diferencias con lenguajes "más sofisticados".
  • Sigue dando feedback al equipo de Go, observando la lenta evolución del lenguaje y manteniendo su aporte a la comunidad.

• Cada vez que leo críticas a Go, igual voy a seguir usándolo.

  • En teoría tiene muchos problemas, pero en la práctica sigue siendo un buen lenguaje de programación.
  • Me gusta el manejo explícito de errores. Tampoco me molestan demasiado las desventajas de otros lenguajes.
  • Quienes son sensibles a las desventajas de Go seguirán quejándose. Hay que elegir el lenguaje que mejor le funcione a cada quien.

• Cada vez que uso otro lenguaje, me dan ganas de volver a Go.

  • Con Go solo lo instalas, descargas el código y te pones a escribir. No hay que preocuparse por versiones, runtime, configuración, herramientas de build ni package manager.
  • Rust también puede ofrecer una experiencia parecida. Cuando uso Python, Typescript o Java, la programación me da miedo por los problemas relacionados con la configuración.

• Estaba buscando un Python mejor. Go era la opción obvia, pero no me gusta su sintaxis.

  • Rust usa muchos caracteres especiales, y Lisp no me gusta por los paréntesis y la notación polaca inversa.
  • Compilo código Python con Nuitka para distribuir binarios. Me interesa la compilación AOT de C#.
  • Me gustan Nim y Crystal, pero sus comunidades pequeñas son una barrera. Nim es un lenguaje excelente a pesar de su comunidad reducida.

• No entiendo por qué Go y Rust se comparan tan seguido. Sería más apropiado compararlo con Java.