Conclusión clave
- El lenguaje Go no siempre es más rápido. De hecho, un runtime de JS puede llegar a ser más rápido.
- Go presume simplicidad y eficiencia, pero en entornos reales a veces su rendimiento puede ser peor de lo esperado.
- En particular, en situaciones con mucho I/O de base de datos, puede rendir peor que un runtime de JavaScript como Bun.
Resultados del benchmark
- Go mostró mayor throughput de solicitudes y menor uso de memoria, pero el uso de CPU fue entre 2 y 3 veces más alto.
- Sin embargo, en entornos reales con mucho I/O de DB, Bun (combinando el framework Elysia y la librería MySQL2) mostró un rendimiento más estable y eficiente.
- El router HTTP estándar tuvo bajo rendimiento, y al cambiar al framework Fiber se obtuvo una velocidad de respuesta similar a la de Bun. (¡No usen el router HTTP estándar de Go!)
Ventajas de Go en las que pensé al hacer este benchmark
- Ofrece varios tipos primitivos y seguridad de tipos.
- Despliegue en un solo binario: se puede desplegar como un ejecutable simple, eliminando dependencias de runtime.
- Goroutines: permiten manejar procesamiento paralelo de forma eficiente y, si se usan bien, aprovechar al máximo el hardware.
Limitaciones y margen de mejora que sentí con este benchmark
- Sospechas sobre el rendimiento del driver de MySQL: el
go-mysql-driver de Go es estable, pero lento, y parece rendir peor que mysql2 de JavaScript. (Claro, también podría estar equivocado)
- En tareas sin conexión a DB, Go muestra mejor rendimiento. Tal vez eso sea algo obvio.
- Bajo rendimiento del router HTTP: por salud mental, ¡usen Fiber u otro framework!
Por qué, pese a no estar satisfecho con el rendimiento, quiero seguir usando Go
- La seguridad de tipos de Go, el despliegue en un solo binario y el rendimiento de procesamiento paralelo con goroutines siguen siendo muy atractivos como desarrollador. Los tipos que TypeScript no puede cubrir y la posibilidad de desplegar un archivo binario único sin necesidad de
npm install fueron ventajas realmente grandes.
- Viendo que todavía hay margen para optimización adicional, decidí seguir aprendiendo y usando Go.
Un mensaje para los desarrolladores
- Todos los lenguajes y tecnologías tienen ventajas y desventajas. Creo que con Go pasa lo mismo.
- Más que decepcionarse por el rendimiento de Go, sería bueno aprovechar bien sus fortalezas y seguir buscando formas de superar sus límites de rendimiento.
- Escribí este artículo para compartir con los desarrolladores que usan Go que también existen este tipo de análisis y resultados.
16 comentarios
Es totalmente fuera de tema, pero la fuente IBM Plex Sans KR está hermosísima.
A mí también me gustó mucho esa fuente y la usé, pero hay justo un solo detalle que me deja algo inconforme: en monitores de baja resolución no se ve particularmente bonita. Jaja, ¡en un monitor 5K sí se ve realmente hermosa!
Creo que hay que ser realmente cuidadosos al criticar algo.
No está claro si es un problema a nivel del lenguaje, de una librería específica o del código en sí, y afirmar públicamente que algo es malo sin dar suficiente información para que otras personas puedan reproducirlo
parece no ser algo agradable para quienes forman parte de ese ecosistema, aunque esa no haya sido la intención.
¡Hola! Antes que nada, gracias por dejar una opinión tan valiosa. Entiendo desde qué sentir compartiste tu comentario sobre lo que mencionaste y, si en algún momento te pareció que estaba criticando el futuro del lenguaje Go o a sus usuarios, quiero reiterar que esa no era mi intención y ofrecerte mis disculpas una vez más. Y si te parece bien, al hacer clic en el título del artículo encontrarás varios datos y también otras entradas de blog de otras personas, así que creo que, si las lees (aunque sea un poco largo), podrás entender con más claridad cuál era mi intención.
Yo siento que un lenguaje se parece en cierto modo a un automóvil. Pienso que se parecen en que cada auto tiene distintas ventajas y desventajas, cada uno implica costos diferentes al momento de comprarlo y, aunque parezcan cumplir el mismo rol, persiguen valores distintos. Por supuesto, también me parece totalmente natural sentir un cariño especial por ese vehículo y apreciarlo mucho. Yo también amo mi auto y confío en su fabricante.
Aun así, yo también tengo cosas que me decepcionan o me generan inconformidad sobre mi auto, y quienes reseñan modelos de vehículos de forma periódica siempre comparten sus análisis comparándolos en distintos aspectos con los modelos competidores. Si alguien dice que la transmisión de mi auto no rinde bien o que consume demasiado combustible, la verdad es que a mí tampoco me agrada escucharlo, pero aun así trato de separar al conductor de su auto. Además, procuro informarme más sobre el auto que manejo, tanto en sus puntos fuertes como en sus puntos débiles. Tal vez algún día termine manejando otro auto, pero la experiencia de conducción que tengo ahora también me seguirá sirviendo entonces.
En la versión resumida no pude mencionar mucho de eso, pero en el cuerpo del blog concluí diciendo que, a pesar de los puntos débiles de Go, sus ventajas siguen siendo mayores, así que quiero seguir usándolo (= conducirlo). Como cada lenguaje persigue valores y fortalezas distintas, suelo intentar usar la mayor variedad posible de lenguajes (= vehículos). Por eso también quiero pasarme a Go, aun teniendo ya un runtime de JS que me funcionaba bien.
Pensé que había escrito el artículo con bastante cuidado, a mi manera, para evitar al máximo una discusión innecesaria entre lenguajes. Aun así, si hay personas de la comunidad Gopher a quienes este texto les haya resultado molesto, espero una vez más que puedan tomarlo con calma, y cierro este comentario aclarando que soy un coder romántico que también ama el lenguaje PHP, por más críticas que haya recibido.
En el texto original, el autor incluye su propio análisis sobre las partes lentas y, aun así, explica por qué seguiría usando Go, así que no entiendo bien por qué recibiste este artículo como un juicio de valor.
Aunque es un TMI, la librería estándar de Go ha ido perdiendo rendimiento con el tiempo. La razón principal es el trade-off frente a las numerosas vulnerabilidades de seguridad reportadas, a medida que se agregan diversas funciones para cumplir con los estándares RFC.
Últimamente, para poder pasar la certificación FIPS, se espera que probablemente el costo en rendimiento sea todavía mayor.
Si se elimina todo este contexto y simplemente se deja escrito que el rendimiento es malo para el escenario específico más simple, creo que eso basta para provocar malentendidos en muchas personas.
Estoy esperando la versión 1.0 de tsboard jaja
¡Gracias por esperar! Seguiré trabajando con mucho gusto jaja
Creo que no hay una razón particular para que JS sea lento cuando usa JIT.
Exceptuando multihilo, estabilidad y demás..
Esto también fue algo que descubrí recién gracias a este benchmark, y creo que me atrevo a decirlo porque el nivel de estabilidad tampoco presenta grandes problemas. Es cierto que el multihilo definitivamente requiere orquestación (no sé si sea correcto decirlo así), así que es un poco engorroso.
¿Soy el único al que no le funciona el sitio?
¡Hola! Gracias por avisarme en los comentarios jaja. Todavía no he podido mover el sitio a un hosting, así que a veces hay problemas de acceso. Haré lo posible por solucionarlo lo antes posible. (Por ahora, una mini PC en mi casa está dándolo todo 😂)
Oh, ahora sí funciona. ¡Lo leeré con atención!
Movimos el sitio de una mini PC casera a un servidor virtual del tamaño de un cuarto pequeño...! Hoy, inesperadamente, muchísimas personas nos visitaron y tuvieron que irse, pero ahora les informamos que ya no hay problema.
Me pregunto si al hacer pruebas con el driver
github.com/jackc/pgx/v5y PostgreSQL se obtendrían resultados distintos.Yo también tengo curiosidad de si este resultado se limita a MySQL o si aplica a todos los escenarios que usan una base de datos. Supongo que en algún momento otras personas compartirán sus resultados jaja