Mi luna de miel con el lenguaje Go ha terminado. Este artículo va a tener un tono diferente de lo que he estado publicando el año pasado... Y siempre me siento mal escribiéndolo, porque, inevitablemente, discute cosas en las que mucha gente ha trabajado muy duro. A pesar de eso, aquí estamos. Después de haber invertido miles de horas en el lenguaje, y haber implementado varias piezas críticas (para mi empresa) de infraestructura con él, desearía no haberlo hecho.
Comentarios
Un pelin exagerado, y sí, la mayoría son “Go es una mierda porque Windows no es POSIX”. Bueno, quizá Windows sea lo que es una mierda no?
Suerte tiene que no se ha encontrado (aun?) con el bug de Windows/Hyper-V que causa que el reloj del sistema se adelante en el tiempo al ejecutar programas escritos en Go.
O un deadlock en el kernel de Windows que bloquea servidores con llamar a cierta api de manejo de tiempo (que el runtime de Go llama con frecuencia) mientras existe otro proceso pineado a una CPU con prioridad máxima.
Está claro que Windows no es una prioridad para Golang, pero tampoco les culpo. Windows es un cancer y deberíamos de hablar seriamente sobre dejar de desarrollar software para este SO.
#5 No conocía esos bugs. Voy a buscar un poco.
Evidentemente Rust es mejor en casi todo excepto en la "velocidad de desarrollo".
Los miles de horas serían el triple con Rust.
La mitad de los argumentos son que en Windows no va igual. La otra mitad que por debajo del capó hay tralla. Me va a decir alguien que en node o en cualquier otro lenguaje de este tipo no?
#1 Mejor usar un lenguaje que no te engalla, no se mete en medio, y no endulza la realidad. C
#2 Bah... el compilador de C es un entrometido, ensamble usted y déjese de engallarse.
https://www.nasm.us/
#2 Es de la misma gente. Y el mejor C es el de plan9/9front, los demás son barroquismo. Y Go es el lenguaje que encarna la filosofia de compilad estático de plan9 y multiplataforma "pa tontos". En caso de plan9, cambiando el numero del compilador: 8c i386, 9c amd64, etc... En el caso de Go, asignando las variables GOARCH y GOOS a lo que desees antes de compilar.
#7 Go no necesita a POSIX para nada, hay hasta un port para plan9/9front (nada raro como digo).
#9 No lo necesita, pero está claro que su implementación del sistema de ficheros está muy basada en Posix, o mejor dicho, en linux-like.
#2 Si consigues usar Win32 bajo C no creo que tengas problemas de paro en la vida.
#11 La winapi está bien diseñada, incluso desde assembler se deja querer. La `stdcall` es mucho más fácil de manejar que `cdecl` y desde C es usar windows.h e ir pasando el handle paquí-pallá. Hacer GUIs desde C eso ya es otra cosa más jodida, pero para eso está C++
#2 c es una quesadilla. De las mexicanas.
#2 y en el que hacer software concurrente y basado en hipertexto es una pesadilla (lo intenté durante un tiempo)
#20 solo hace falta pthread, poll/select, y una bajada permanente de tu nivel de cordura.
Los problemas que cita no están relacionados con go, sino con los sistemas operativos no POSIX, como Windows. Que se pase al php y compruebe como todas las rutas con / fallan en windows.
#7 __DIR__
#14 __PATH_SEPARATOR__ en realidad. Absurdamente largo y poco usado.
#15 en verdad es DIRECTORY_SEPARATOR, ya ko se si simplemente DS es de PHP o de PrestaShop.
De todas formas no suelo usarlo, el intérprete de PHP de Windows admite rutas con ambos separadores, incluso mezclados.
https://www.php.net/manual/es/dir.constants.php
Gallir es un enamorado de Go, estaría bien saber su opinión al respecto.
He de decir que los problemas de velocidad que hicieron que los (de Discord creo), se pasaran a Rust, estaban mejor solventados con Go 1.13 (y ellos usaban una version bastante anterior), y que Go 1.14 corrige mucho más allá esos problemas de latencia.
#10 Si. La prueba de Discord no me pareció nada concluyente. Creo que hay otros motivos detrás de esa decisión. Incluso mirando las gráficas que publicaban, los picos en que el sistema iba lento eran muy bajos. Y Rust no tenía esas variaciones pero gastaba un poquito más de CPU. O sea que el trabajo que hace el GC de go de vez en cuando, se convierte en Rust en un trabajo constante, que aplana ligeramente la curva.
En todo caso, Go versus Rust es como McLaren versus Ferrari. Los dos están en la Fórmula 1. Otras arquitecturas apenas pueden soñar con la velocidad de ejecución que dan con tan poco esfuerzo.
#13 El problema de Rust es el esfuerzo de desarrollo. Sin contar con ese esfuerzo todo lo demás son ventajas.
Pruebas básicas de rendimiento en una de las áreas fuertes de go, el desarrollo web:
https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=fortune&l=yykf0e-f
P.D.: Casi todos los desarrollos actuales los realizo en go por el balance entre velocidad de desarrollo y resultados.