Feda /dev/ - No Javascript allowed

#51211desu:

vais a notar un salto abismal en la facilidad de usarlo. cualquier fpero escribe go mas rapido que java en 2 semanas. para escribir rust al mismo nivel necesitas 2 años.

#51211desu:

a velocidad de arranque lo vas a notar, pero que clase de servicios son?

En el caso mas "grave" es un monolito multimodular que tarda su buen minuto y pico en arrancar, súmale los healthchecks, conectarse a colas, caché, etc... A esto añade que está en un baremetal y sale bastante caro tener uno en stand by para cuando sea necesario (todo esto es otra historia y viene a raiz de las necesidades de un cliente). Al final el coste y el tiempo necesario para levantarlo hacen que se quiera pasar a algo mejor (en general).

#51211desu:

y a nivel de consumo de recursos y rendimiento, si es spring 3 async y todo bien hecho vais a ir varios miles de peticiones por segundo a un 10% de cpu en la instancia mas barata de aws. rust sirve para optimizar la tail latency, el 99 percentile y el max... porque creeis que teneis esas necesidades?

Ahora mismo tenemos versiones de spring y java bastante antiguas en este monolito, el coste general de actualizarlo es grande y por poca diferencia de coste/tiempos sale rentable rehacerla pensando en el futuro.
Sobre las necesidades, sin entrar demasiado en detalle, eventos en vivo de todo tipo, con cientos de miles de conexiones en momentos puntuales y muchas suscripciones a contenidos varios que se deben actualizar en tiempo real.

#51211desu:

usais quarkus porque os hace gracia y rust porque os hace gracia.

Nope, de momento no los usamos. Estamos analizando muchas situaciones, costes, rendimiento, etc... (hay varios departamentos haciendo pruebas cada uno mirando un poco por lo suyo) y se baraja Java 21 + Spring Framework 6, Java 21 + Quarkus y Rust. Con varios analisis, pruebas de estrés y demás y según el aspecto que se analice algunas elecciones son mejores que otras, pero ninguna es la definitiva a día de hoy.

Luego ya está el tema de pequeños microservicios transversales que se están haciendo con diferentes tecnologías para irlas probando, etc...

Aquí la idea no es seguir una moda o un gusto, sino tener el mejor producto posible (y que funcione fino)

EDIT: al final lo que diga el CTO junto con su corrillo es lo que se hará, pero por mi parte lo unico que puedo hacer es proporcionar toda la info qu epueda con pruebas tangibles y si me dicen que tenemos que hacer las cosas nuevas en .net, Go, Rust, Java, Python, JS o lo que sea pues se acabará haciendo

#51213pantocreitor:

según el aspecto que se analice algunas elecciones son mejores que otras, pero ninguna es la definitiva a día de hoy.

por que?

#51219 El primer ejemplo que se me viene a la mente es el driver reactivo de Oracle. Dónde mejor funciona es en Spring, luego en Rust (muy poca diferencia) y dónde peor va es Quarkus.
Redis funcionaba también diferente pero este no recuerdo el resultado.
Consumo de memoria, cpu, GC y demás (aquí se fijron mucho los de infra para temas de presupuestos y tal) Rust se come a Spring o Quarkus, al igual que en rendimiento en pruebas de carga y estrés con _150k de suscripciones a conteido live con una media de 10 actualizaciones/s por evento y unos 200 eventos.

Por otro lado desventajas ya no de tipo tecnológico son en base al conocimiento. Tenemos gente que usa varios lenguajes, pero nadie es un "experto" en Rust.

Las pruebas no se han hecho sobre el monolito, sino con las tecnologías que se quieren probar, los datos del monolito los tenemos porque se lleva usando desde hace unos 10 años y hay datos para aburrir

Y las pruebas son CPU, de IO he visto poca cosa (se ha hecho algo pero ahí no he metido mano).

Según lo que dices deberíamos rehacer la plataforma en Go o partir el monolito y usar Spring actual (hay que rehacer casi todo), pero que hagamos pruebas y analizcemos opciones lo ves mal. No entiendo el punto de vista la verdad.
¿Ves mal que se tome una decisión con datos tangibles? Desde mi punto de vista, analizar una situación y hacer pruebas para ver que solución de las propuestas te da mas benficios y menos problemas respecto a otras es un buen camino a seguir (partiendo de que el monolito se va a partir, eso es algo que está claro).

El tema está en que tu propones 2 opciones y nosotros estamos barajando varias mas (de hecho Go está como opción, pero nadie ha hecho analisis o pruebas).

Al final la parte dónde curro consiste en eso, invertir tiempo en mejorar y si se necesita algún componente transversal crearlo de la mejor manera posible.

Por cierto, si tuviese que tomar yo decisiones, por menos de 150k no me mojo jajajajaja

#51223 bastante mal si, por 20k te doy la respuesta.

#51223pantocreitor:

Según lo que dices

eso no he dicho.

vuestor procedimiento esta mal, las pruebas son datos incorrectos, bastante perdida de tiempo si.

como dije atras, el que lleva eso no tiene ni idea de lo que hace.

#51234 Google sigue con los 3 meses de remote work fuera de USA?

Si vas a España avisa y me apunto al coworking. Si quieres venirte a esquiar en invierno te invito.

#51234 La verdad es que Málaga es muy top, llevo ya varios años iendo para Enero y los espetos son lo mejor que hay en esta vida.

#51220 Una cosa no quita la otra. Que para hacer CRUDs de mierda sea más rápido que Java no signifique que no tenga nada de ecosistema y que si buscas algo no hay respuestas más allá de 2016. "Eso significa que está maduro el proyecto". Una polla, eso significa que no lo usa ni dios.