edición general
10 meneos
278 clics

Me quiero bajar de la montaña rusa de Golang [ENG]

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.

| etiquetas: google , go , golang , rust
8 2 2 K 15 tecnología
21 comentarios
8 2 2 K 15 tecnología
Comentarios destacados:    
  1. #1 --630762--
    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 K 17
  2. box3d #2 box3d
    #1 Mejor usar un lenguaje que no te engalla, no se mete en medio, y no endulza la realidad. C :-D
    2 K 31
  3. comadrejo #3 comadrejo
    Evidentemente Rust es mejor en casi todo excepto en la "velocidad de desarrollo".

    Los miles de horas serían el triple con Rust.
    1 K 19
  4. eltoloco #4 eltoloco
    Gallir es un enamorado de Go, estaría bien saber su opinión al respecto.
    0 K 10
  5. #5 --589369-- *
    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.
    7 K 63
  6. comadrejo #6 comadrejo *
    #2 Bah... el compilador de C es un entrometido, ensamble usted y déjese de engallarse. :troll:

    www.nasm.us/
    0 K 7
  7. cosmonauta #7 cosmonauta
    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.
    0 K 11
  8. cosmonauta #8 cosmonauta
    #5 No conocía esos bugs. Voy a buscar un poco.
    0 K 11
  9. #9 --625430-- *
    #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).
    1 K 12
  10. #10 --625430--
    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.
    0 K 8
  11. #11 --625430--
    #2 Si consigues usar Win32 bajo C no creo que tengas problemas de paro en la vida.
    0 K 8
  12. cosmonauta #12 cosmonauta *
    #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.
    0 K 11
  13. cosmonauta #13 cosmonauta
    #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.
    2 K 26
  14. #14 --604882--
    #7 __DIR__
    0 K 8
  15. cosmonauta #15 cosmonauta
    #14 __PATH_SEPARATOR__ en realidad. Absurdamente largo y poco usado.
    0 K 11
  16. #16 --630762--
    #2 c es una quesadilla. De las mexicanas.
    0 K 7
  17. box3d #17 box3d
    #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++
    0 K 8
  18. comadrejo #18 comadrejo
    #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:
    www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=fo

    P.D.: Casi todos los desarrollos actuales los realizo en go por el balance entre velocidad de desarrollo y resultados.
    0 K 7
  19. #19 --604882-- *
    #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.

    www.php.net/manual/es/dir.constants.php
    0 K 8
  20. #20 --630762--
    #2 y en el que hacer software concurrente y basado en hipertexto es una pesadilla (lo intenté durante un tiempo) :shit:
    0 K 7
  21. box3d #21 box3d
    #20 solo hace falta pthread, poll/select, y una bajada permanente de tu nivel de cordura.
    1 K 15
comentarios cerrados

menéame