Si por mí fuera echaría CV a Go, pero aún no tengo nivel para cobrar lo que cobro picando Java. A ver si en un salto o dos lo consigo. Por lo demás, a Go le faltan cosas importantes como los enums, hay que montar un cipostio de miedo para tener esa funcionalidad porque no existe por defecto.
Editado por moderador: muevo a nuevo hilo, debido al "debate generado"
#1Kaledros:a Go le faltan cosas importantes como los enums
te he dicho muchas veces que abras un hilo porque lo que dices no es verdad
// int mapping
const (
Summer int = 0
Autumn = 1
Winter = 2
Spring = 3
)
// string mapping
const (
Summer string = "summer"
Autumn = "autumn"
Winter = "winter"
Spring = "spring"
)
???
#2 Porque no soporta mapping.Summer.toString() o similar y tienes que montarte tú mismo el mapeo a String como acabas de hacer.
#3 Para que quieres una string?
El segundo código que hay de enum está mal, deberías siempre usar uint8, uint16... usar strings como enums es una mala práctica porque consume más memoria y es más lento en las comparaciones.
hacer el toString para devolver un DTO o similar es trivial... lo malo es que no tienes pattern matching exhaustivo pero puedes cazarlo facilmente con un default que haga panic.
el otro dia pique esto en ts... que problema hay?
#4desu:Para que quieres una string?
Porque quiero enviar "summer" como valor de una key de un JSON por HTTP, por ejemplo, en vez de un cero. O compararla con otro valor que me llega de otro servicio que no tiene por qué compartir esa clase enum como librería.
#5 Hacer un mappeo tanto para devoler un DTO como para parsear un DTO es una mejor practica siempre. Y en Golang la manera idiomática de hacerlo es un custom Marshall y Unmarshall...
Son 2 líneas de código cada vez que añades un campo o cambiar un valor si cambia el contrato.
Donde esta el problema?
También tienes la String() interface si quieres hacer logs. Que funcionara con cualquier libreria que hacepte la interface, que en Go es todo. HTTP, logs, filesystem etc...
Si el día de mañana cambias la libreria de json, también funcionará todo, porque Go.
Si cambias la librería HTTP, para el cliente o para el servidor, también funcionará todo.
#6 No es un problema per se, pero te obliga a escribir código que en el resto de lenguajes está escrito como parte de la librería estándar. Y eso es muy de Go, dejarte libertad para hacer como quieras algo que el 99,999% de la gente hace igual en todas partes. No, no es un defecto, pero es innecesario.
#7 Existen motivos por el cual esto no está en la estándar, como por ejemplo el alineamiento en memoria, las foreign functions, etc.
En Go funcionará, en otros lenguajes no. Te obligará a hacerlo en C.
Estás seguro de que no existe librería alguna que haga esto?
// int mapping
const (
Summer int = 0 `json_value:"summer"`
Autumn = 1 `json_value:"autumn"`
Winter = 2 `json_value:"winter"`
Spring = 3 `json_value:"spring"`
)
Pero vamos, yo personalmente prefiero usar el String() o Marshall() interface, que lo anterior... Me parece mil veces mejor práctica usar los bloques del lenguaje.
De nuevo, no veo como escribir 2 líneas de código es tanto problema con los miles de beneficios que tiene.
¿Por qué no comentas los inconvenientes de otros lenguajes? Porque Go no los tiene.
Todo sin entrar en "que es una string", una cadena de u8? como se representa en memoria? como lo transfieres?
PS: En Rust también es así por ejemplo. Y me la juego y digo que en Swift también que es un lenguaje moderno. Sin usar Google estoy seguro, me la juego, que Swift se hace igual.
#8desu:¿Por qué no comentas los inconvenientes de otros lenguajes? Porque Go no los tiene.
Por eso no he dicho que esa forma de mapear enums a strings sea un problema.
#9 Dices que Go no tiene enums, y Go tiene un soporte de enums mejor que python, js, java (jvm), php, y para mí hasta que C99 por la ergonomia.
Go tiene el mismo soporte de enums que Rust y estoy seguro de que Swift y demás lenguajes modernos de los últimos 10 años. Me sorprende que tantísimos diseñadores de lenguajes y compiladores hayan hecho el mismo error.
Sabes para que sirve un enum? explicamelo. (ps: se que no lo sabes, por curiosidad).
No solo go, rust, zig, todos estos lenguajes hipsters que están saliendo tienen unas carencias brutales porque según los subnormales que los desarrollan son cosas de pollavieja que no son prioritarias/no les interesa añadir.
Luego llega alguien a hacer una app no trivial y oh sorpresa.
#13 Por qué? un enum es estático en tiempo de compilación.
En Go usas la keyword "const" para expresar eso. Qué problema hay?
En el curro tenemos una codebase de 2m loc, varios servicios entre clusters de Kubernetes, cloud runs, y otras movidas, y miles de funcionalidades. Créeme, no vas a encontrarte ninguna limitación usando Go.
Si es por quejarte de X feature, puedo sacar 10 mierdas de Java por cada queja de Go que tengas.
Ah y ya no me acordaba.
Sabes para que sirve un enum? explicamelo. (ps: se que no lo sabes, por curiosidad).
Estoy seguro de que el 99% del foro, y de programadores NO SABÉIS para qué sirve (y para que se inventó) un "enum".
Ese es el nivel.
Y 99% es generoso, yo diría a ojo que 1 de cada 10 mil programadores lo sabe.
#14 Problema? Aparte de literal ninguno.
Es exactamente la misma idea que tuvo PHP cuando hizo posible que una constante pudiera ser un array asociativo y que eso fueran los "enums" de PHP...obviamente se les mando a tomar por culo y a los enums...se les llama enums...
#15 tampoco te vas a encontrar ninguna limitación con otros tantos lenguajes, o qué es lo que se hace en go que, por ejemplo, por limitaciones de la jvm no puedas en java?
#19Wei-Yu:qué es lo que se hace en go que, por ejemplo, por limitaciones de la jvm no puedas en java
Arrancar un servicio en milisegundos en lugar de en segundos.
#22 un profiler en la libreria estandard que funciona y puedes tener siempre accesible y desplegado con 0.X% de impacto en performance...
#22 el warm up se nota en runtimes más jebis pero al final del día tampoco te cambia la vida, al igual que tener una imagen con 1/3 del memory footprint.
Si es para tráfico in flight aporta mucho más el tradeoff, pero si es para el momento inicial, limar milisegundos en el startup es un caso de uso un poco nicho.
#23 eso está guay pero de base no tengo un punto de referencia con jvm/clr. Así que tampoco sé cómo de relevante es, he probado una mierda que te venden en azure para el clr que está al nivel de no tener nada, pero más allá de eso poca cosa.
#24Wei-Yu:al igual que tener una imagen con 1/3 del memory footprint.
menos memoria = más eficiencia = más velocidad
estás diciendo que go va 1/3 más rápido que java.
depende del tráfico, io bound puede ser un 20%, cpu bound es más.
#24 El mismo servicio (porque lo estamos migrando) en Go responde en 30ms mientras que en Java (sí, con Spring, pero pal caso) tarda casi 10 veces más. Cuando lo que devuelves pinta una pantalla que ve el usuario la velocidad es crítica.
De hecho ahora el cuello de botella son los alineadivs XD
#26 imagínate en el dinero y perdida de tiempo que ha sido tener esa mierda en spring durante años...
Hablamos de que una máquina que te podía costar 100 euros al día, ahora puedes hacer lo mismo y más rápido por 10 euros... un orden de magnitud de reducción de costes. Y varios órdenes de magnitud en reducción de bugs y mantenimiento.
El mayor cuello de botella es el salario de los fperos de java que montaron el Spring en primer lugar, todos a la puta calle.
#26Kaledros:El mismo servicio (porque lo estamos migrando) en Go responde en 30ms mientras que en Java (sí, con Spring, pero pal caso) tarda casi 10 veces más.
Esto lo he escuchado mucho pero de casi cualquier cambio stack... Habéis llegado a hacer benchs de un workload concreto para aislarlo y correlacionar entre ambas apps?
yo los benchs de go/jvm/clr/$runtime_random que he visto por inet acababan todos tendiendo a prácticamente los mismos numeritos, con la excepción de rust y cosas así por motivos obvios
#28 Nosotros si, test de carga, tener mismas instancias con el mismo % de tráfico todo en producción.
Antes tenías un equipo de 10 fperos de java, pon 50k al año cada uno, y costes de máquinas de 10k al mes. 500k + 120k. Que en 1 año de desarrollo el 80% del tiempo lo dedican a mantener SPRING y resolver BUGS DE SPRING.
Ahora puedes tener a 3 programadores Go, por 80k al año, y costes de 1k al mes. 240k + 12k. Y el 90% del tiempo lo dedicarán a NUEVOS FEATURES o NUEVOS SERVICIOS.
Hacer Java a partir del año 2015 aprox, es una mala decisión técnica en todos los sentidos.
De hecho tenemos benchmarks de cambiar de intel a ARM en amazon y también te puedo decir los márgenes exactos. ¡Que son también sobre un 30%!!! en java CONTANDO LOS DESCUENTOS DE AWS.
#27desu:imagínate en el dinero y perdida de tiempo que ha sido tener esa mierda en spring durante años...
El dinero y la pérdida de tiempo no ha venido por Spring, ha venido porque durante cinco años la tarea de seis equipos ha consistido en migrar un monolito de PHP del año 2005 a microservicios Java. Es decir, que lo único en que han estado trabajando desde 2018 (multiplica sueldo + gastos de infra de un equipo de 40 personas) ha sido en mejorar la legibilidad y la escalabilidad. En valor de producto la mejora ha sido CERO porque hace exactamente lo mismo que antes.
Con Go las cosas se hubiesen migrado mucho más rápido (es infinitamente menos verboso y necesita mucho menos boilerplate), siendo el resultado más eficiente e igual de escalable. Por lo que sea, el o los responsables de esa decisión, que ha costado millones de euros, ni sabe de lo que hablo ni va a pagar las consecuencias.
