#29 buen pajote pero estás hablando del e2e entre una app y otra, caundo la pregunta la hacía sondeando por benchs que aten el cambio a la implementación.
#30Kaledros:ni sabe de lo que hablo ni va a pagar las consecuencias.
Seguramente NI SIGUE EN LA EMPRESA.
"PUESTOS DE RESPONSABILIDAD" lo llaman
HAHAHAHAHAHHA
#31 si también, claro, por supuesto que se ha hecho.
que golang es mejor lenguaje para backend lleva siendo así 10 años ya, que vienes a preguntar sobre benchmarks y casos de éxito jaja
otro tema es que a tu empresa le da igual "usar el mejor lenguaje" y quiere hacerlo en python o node. como si se fuman cuatro porros que tiene que ver eso con la conversación?
#33 go usa menos memoria, es más eficiente, por tanto, es más rápido.
cuanta menos memoria use y mejora sea el acceso de la cpu a esta (idealmente siempre lineal y secuencial) mejor tu codigo de mierda.
si ejecutas una función de manera aislada quizás ves un 2% de mejora entre JVM y Go y dirás, menuda mierda. haciendo un microbenchmark con multiples ejecuciones y randomizando el acceso a memoria para tener la cpu siempre en un estado limpio.
pero en el mundo real, vas a ejecutar miles o decenas de miles de esas funciones en paralelo, así que ese 2% resulta que es un 20-30% que es lo que hablamos.
y ese 2 a 20-30 se debe a que todas las ineficiencias de la JVM escalan linearmente. y todos los problemas se agravan.
como go es la mierda con gc que mas facil y mejor funciona existe hoy en dia, es el mejor.
si te interesa ganar otro % usa rust zig o c.
si me dijese alguien, go es la polla en performance, pero es que tiene mas bugs que spring, y en lugar de estar 80% de mi tiempo arreglando bugs de spring estoy 90% arreglando bugs de Go, pues te diria que java es mejor, pero es que ademas de ser mas rapido es mil millones de veces mas productivo en el mundo real y comprovado.
xq por esta narrativa, la gente no usa rust, zig o cpp. xq ademas de pagar mas a los programadores, el beneficio es minusculo si no tienes la escala necesaria. esta demostrado que la gente en rust cobrara mas y la curva de aprendizaje es superior.
no desarrollaste ): no tenías ejemplo del trabajo?
por supuesto que se ha hecho.
al menos con esto entendía que habíais hecho eso en tu curro, aunque si me pasas benchs que lo consideren me vale también
en la jvm ya está loom? estaría guay ver el tema de las allocs para las fibras comparado con lo que hay ahora
#35 no entiendo a que te refieres, tenemos un par de microservicios que son una función o dos cada uno, porque son CPU bound y escalan horizontal. y es lo que he desarrollado.
#35Wei-Yu:no tenías ejemplo del trabajo?
hay una conferencia donde enseñaremos algo de las migraciones, pero no sé cuando era.
sobre tu pregunta orignial no hablaba de e2e de cliente si te refieres a eso, con una arquitectura de muchas capas de microservicios anidados o asi... te hablo de mejora por servicio individual porque cada mejora es e2e en nuestro caso. solo hay 1 capa de load balancing el 99% de los casos.
#36 pues si te enteras y me lo dices lo agradecería, yo no he visto nada que de verdad me confirme el hype de la gente.
al final hay muchas cosas muy opacas más allá de que si el threading es stackless o stackful o las syscalls que se puedan hacer porque el compilador de algo así es un puto monstruo y a saber la cantidad de conocimiento embebido hay ahí + la variabilidad del hardware que por mucha virtualización sigues dependiendo de lo que tiene el vendor puesto en metal
hace poco estuve leyendo un issue de .net en el que se encontraron que una optimización "rutinaria" (rutinaria para ellos que van full galaxy brain claro) en el arm de mac iba como 3 ó 5 veces más despacio por una movida concreta del instruction set que tienen
#37Wei-Yu:pues si te enteras y me lo dices lo agradecería, yo no he visto nada que de verdad me confirme el hype de la gente.
que quieres ver exactamente, no entiendo la pregunta.
esta todo benchmarkeado, e2e, entre servicios directamente no pasa por loadbalancer u otros servicios, función de un servicio.
cliente => alb => gw => service => db
cliente => alb => gw => service => service => db
cliente => alb => gw => service => service
gw => service ...
service => service
=> service
por ejemplo en ms entre servicios, o un e2e, la mejora en respuestas es muuuuy poca. si antes tardábamos 120ms, ahora tarda 110ms. o si algo tardaba 60ms ahora tarda 55ms. la diferencia es que ahora consume un 30% menos de cpu/mem y le puedes meter 1/3 menos de instancias e incluso meter instancias más baratas.
es lo que te he explicado arriba, medir una funcion no tiene sentido, la mejora la verás al tener miles de funciones en paralelo.
y tambien el througput p95, p99 y pmax ha incrementado mucho. sobretodo con el cambio de intel a arm. si antes el p99 de throughput eran 5k req/s ahora son 9k req/s.
Los costes de cpu/memoria por peticion, con ARM + Go son una locura de baratos el beneficio.
resumen go con arm:
- haces mas peticiones, cuantas? un 40%
- las peticiones son mas rapidas, cuanto? depende si io o cpu, pero ponle un 20%
- ademas las peticiones son mas estables, desviaciones y p9X mejoran una barbaridad
- menos cpu, otro 30%
- menos coste porque las maquinas son mas baratas y tienes menos instancias
- tienes menos bugs y menos mantenimiento, aqui SI, cuanto? un 80% de tiempo de desarrollo arreglando bugs, haciendo bumps de spring de versiones que se rompen... etc etc. A un 10% del tiempo en Go incluso menos. Go en mantenimiento es GOAT.
#37Wei-Yu:yo no he visto nada que de verdad me confirme el hype de la gente
Ponte a usar Go de manera profesional y lo entenderás enseguida.
#38desu:que quieres ver exactamente, no entiendo la pregunta.
esto:
hay una conferencia donde enseñaremos algo de las migraciones, pero no sé cuando era.
hablas como si se fuese a hacer a futuro, si coincide que te enteras bien si no ya intentaré mirar algún día que me de por ahí
#39 para el caso concreto de perf o tienes workloads en la cabeza que poder extrapolar de forma super nítida o ya me dirás cómo te das cuenta de nada currando en empresas distintas con proyectos distintos y particularidades distintas.
#40Wei-Yu:hablas como si se fuese a hacer a futuro, si coincide que te enteras bien si no ya intentaré mirar algún día que me de por ahí
si la he googleado y no lo veo, me suena ahora en mayo - junio, mi empresa es una puta porquería haciendo publicidad.
pero este año 2024 era seguro e imagino que habrá vod.
yo tambien la quiero tener a mano asique ya la compartiré.
Yo me imagino cargando mis bots en java y sería más pobre que las ratas.
No soy fan de go, pero cualquier cosa q necesite un mínimo de velocidad hoy en día la escribiría en go o en rust. Y tiro por go, porque tengo mil librerías en este campo ya creadas.
Si no necesito velocidad, pues tiro de .net por comodidad y flojera.
#43 Yo me intento imaginar microcontroladores con Java y eso tiene que ser la fiesta de la ineficiencia (seguido con el microPython que se está poniendo de moda)
Posdata: Yo sigo intentando sacar mi bot en Rust. Está siendo una experiencia bastante curiosa
#44 que Java no vale para microcontroladores? Cuando te enteres de que lenguaje corre la tarjeta SIM que lleva instalada tu telefono te da un parraque.
A ver, que GO no lo crearon dos mindundis en un garaje para sus scripts del wow, tampoco es que se use para proyectos de TFG además que la discusión ha pasado de un: <<No tiene enums>> a <<Vale, si los tiene, pero no me gusta la sintaxis>> JAJAJAJA
También os digo, JAVA no tiene nada que envidiar a GO, lo que pasa es que GO tiene unos sponsors detrás que no tiene JAVA y hay hype y esas cosas que les gusta a la gente
#47 La gente que hizo Java popular y usable son los de Sun, y ese equipo se fueron de Java y de la JVM en el 2005... espabilad un rato. Han pasado 20 años.
Java lo llevan mindundis desde hace 20 años que no saben lo que es un puntero. Si no fueran por los aportes de la comunidad como Netflix estarían muertos y a la deriva.
Go tiene al mismo equipo core desde que empezaron, salvo los que se jubilaron ya, y por eso siguen en el top. A cada release, mejor que el anterior. ¿Que como lenguaje es una puta porquería? Sí. Pero ahí está. Si los programadores son unos fperos y no puedes darles un Rust porque se hacen daño, dales un Go.
#46 Un teléfono no usa un microcontrolador
Y no he dicho que no valga, he dicho que tiene que ser bastante ineficiente
#49 sigues sin entenderlo, es la SIM la que corre los apples. La spec original de java card estaba pensada para dispositivos con 256 bytes de RAM https://www.infoworld.com/article/2076617/understanding-java-card-2-0.html
#50 Vamos, como un PIC16F. La pregunta es, ¿cuantas más cosas aparte de leer y grabar datos era capaz de hacer? Porque viendo que en C ya puede costar meter un simple control de velocidad con su línea de comandos (evidentemente sin ser una programación profesional)
