Feda /dev/ - No Javascript allowed

#55833 OpenAI se ira a la mierda cuando hagan la IPO y los bonus de los directivos vayan en función del rendimiento de la acción, igual que le ha pasado a toda tecnológica habida y por haber

#55835 Relaja la raja que te está empezando a comer el personaje con todas las faltas de respeto a la gente del hilo

#55837 No estoy defendiendo a nadie, estoy diciendo que el cáncer de todas las tecnológicas es exactamente el mismo independientemente del nombre, siglas o producto y que todas acaban por morir de exactamente el mismo síntoma que es el corto placismo para que la acción suba a costa de hipotecar el futuro de la empresa. Y esto también se le puede achacar a Google

Por una vez estaría genial que tuvieras una conversación civilizada sin tener que recurrir al insulto o a la mofa pero creo que es esperar demasiado de ti

#55841 A ese le enseñó Desu.

No dudaré en contactar con él para trabajar juntos en el nuevo proyecto.

La putita de Sam puede chupar polla de Elon y MSFT. Subnormal de mierda.

#55842 Hable una vez con un compañero suyo para una startup de ML

otra cabeza cortada, tapada con el release de gpt4-0

#55845 No sé qué es peor si eso o "superalignment lead" xD

#55821Kaledros:

Tiene gracia porque el servicio tiene que usar concurrencia porque es un servicio de alta disponibilidad, así que estoy por reescribirlo en Go y decirles que si necesitan concurrencia y alta disponibilidad se busquen otro lenguaje que lo haga mejor.

¿Podrías comentar porque se te queda corto Java? Nunca he tenido ocasión de ver un caso de uso que requiriese Go/Rust por rendimiento/concurrencia/HA y en mi curro son muy Javeros con lo que nunca se plantean otros lenguajes por muy mal que vaya la cosa

#55848 Java se queda cortisimo en rendimiento por tanto mas instancias, luego en eficiencia es malisimo y tienes que poner instancias mas grandes y mas caras, y para finalizar si quieres usar spring3 con reactor, netty esta lleno de bugs que a cada nueva minor version se rompe algo y tardas dias en arreglar.

Nadie que de verdad necesite "alta disponibilidad" y sea buen ingeniero (valore eficiencia, rendimiento, costes en euros $$$) usaria java para nada.

Si consideras tiempos de desarrollo y mantenimiento, tampoco usarías Rust frente a Go. Rust es para gente con buen toque como yo, mínimo. El fpero medio de este hilo como al que citas no sabe ni usar enums.

#55848 Java, de entrada y sin tocar nada, sin Reactor ni nada, es capaz de soportar out of the box bastante tráfico concurrente. Digamos que en el 90% de casuísticas (número sacado del bolsillo) un servicio en Java se basta y se sobra para absorber el tráfico de una app/web enterprise con decenas de millones de visitas únicas al día. Si además le sumas que puedes replicar la app con contenedores y usar un load balancer para distribuir la carga, y levantando más copias conforme vaya haciendo falta, no te tienes que calentar demasiado la cabeza. En mi curro estamos sobre los 50M de visitas únicas diarias y con cinco réplicas del backend vamos que ardemos.

Como dice aquí el terror de los hola mundo, si tienes un concern con la disponibilidad, el rendimiento y la concurrencia, y lo tienes DE VERDAD y no crees que 200M de visitas diarias son una carga inmensa, lo que haces es usar lenguajes que tengan mejor concurrencia y tiempo de respuesta que Java y con los que se puedan implementar servicios web fácilmente. Como Go, por ejemplo.

Lo que pasa es que normalmente el cuello de botella no está en la capa de negocio, está en la capa de persistencia. Es la DB la que suele ahogarse mucho antes de que los servicios empiecen a sudar, generalmente porque cualquier query más allá de un select de una sola tabla es una mierda; como casi nadie sabe optimizar DB en este negocio, las queries complejas son lentas y consumen muchos recursos y la solución suele ser escalar la máquina y a correr. Si la DB se ahoga suele significar que los servicios empiezan a tener latencia en la respuesta, a devolver timeouts, a perchar el Kafka porque no se consumen mensajes y se van acumulando, etc.

He manejado un servicio javero con 12 millones de requests por segundo, creo que la jvm da. Si de verdad necesitas un p99.9 bajo pues te vas a rust, go ni lo nombro.