Python es fácil. Go es simple. Simple != fácil
Los defensores de Go y Python discrepan sobre si los lenguajes “simples” o “fáciles” conducen a mejor software a largo plazo. Se elogia Go por su estilo uniforme, compilación rápida, binarios estáticos y adecuación para proyectos grandes con varios equipos, pero se le critica por su verbosidad, manejo manual de errores, abstracciones débiles y trampas relacionadas con null. Python recibe elogios por su rico ecosistema, su rápida curva de aprendizaje y su sintaxis expresiva, pero muchos señalan la fragilidad de la gestión de dependencias, los límites de rendimiento y la creciente complejidad a medida que han aumentado su popularidad y su conjunto de características.
El boilerplate de Go, el manejo de errores y la verbosidad
- Muchos encuentran tedioso y visualmente ruidoso el boilerplate de Go (especialmente
if err != nil); otros lo ven explícito, predecible y fácil de escanear. - El manejo de errores es objeto de debate: los defensores prefieren retornos explícitos en lugar de excepciones; los críticos señalan que Go no obliga a comprobar los errores y puede continuar silenciosamente con datos incorrectos.
- Se recomiendan herramientas como
go vet, linters y ErrCheck para detectar errores no comprobados, pero los escépticos argumentan que depender de herramientas más boilerplate es frágil. deferse aprecia, pero su comportamiento con alcance a nivel de función hace incómodos patrones como “defer en un bucle”; algunos desearían que tuviera alcance a nivel de bloque.
La simplicidad de Go frente a su expresividad
- Los partidarios sostienen que Go es “simple, no fácil”: pocas características, compilaciones rápidas, BC estable y un estilo uniforme en todas las codebases.
- Los críticos dicen que la simplicidad está exagerada: la falta de tipos suma, enums robustos, tipos no nulos, propagación de errores ergonómica y una stdlib más rica conduce a patrones verbosos y propensos a errores (múltiples
min,filter, etc. hechos a medida). - Los generics y las adiciones recientes a la stdlib (p. ej.,
slices,maps,min/max) mejoran las cosas, pero llegaron tarde.
Go en proyectos grandes y equipos
- Los defensores afirman que Go escala bien para bases de código grandes, de larga duración y con varios equipos: el código “se ve igual”, el rendimiento es “suficientemente bueno” y el tipado estático con concurrencia simple es una ventaja.
- Contraejemplos: las grandes codebases de Go pueden estar profundamente abstraídas con interfaces y métodos diminutos, volviéndose capas tipo Java “de cebolla”. El uso excesivo de
interface{}y trucos inseguros puede causar roturas no locales. - Algunos describen sistemas Go de un millón de LOC como pesadillas; otros dicen que cualquier proyecto de un millón de LOC es doloroso sin importar el lenguaje.
La facilidad de Python y su ecosistema frente a los fundamentos
- Se elogia Python por su baja barrera de entrada, sintaxis concisa, bibliotecas ricas (especialmente para ML/datos) y productividad para scripts y aplicaciones pequeñas/medianas.
- Las críticas incluyen: fricción en empaquetado y despliegue, incompatibilidades de runtime entre versiones, rendimiento, problemas del tipado dinámico/duck typing, monkey patching y un tipado “añadido a posteriori”.
- Algunos sostienen que herramientas como mypy y virtualenv mitigan muchos problemas; otros dicen que persisten los problemas centrales (nulabilidad, falta de tipos suma, velocidad).
Simple vs easy, y alternativas
- La dicotomía “Simple vs Easy” (vía Rich Hickey) se invoca repetidamente: Go apunta a la simplicidad; Python, a la facilidad; Clojure y los lenguajes FP se proponen como “simples” en un sentido más profundo, pero con curvas de aprendizaje más empinadas y ecosistemas más débiles.
- Varios concluyen que la elección del lenguaje debería priorizar el runtime, las herramientas y el ecosistema por encima de la pureza del diseño del lenguaje.