Go no tiene enums

#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"
)

???

#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?

#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.

#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.

#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?

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.

#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.

#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