Enfin si tu vois pas le problème tu vois pas le problème et comment il empire petit à petit soit heureux. Contrairement à tout les autres qui passent leur temps à s'amuser entre Java/Scala/Clojure/Groovy pour mettre un pied après les années 80.
Bon apres, ca depend ce que tu fais aussi.
Pour du backend de consumer web de base, le langage est certe veillot, mais c'est pas la fin du monde, et les perfs sont plutot tres bonnes.
L'ecosysteme autour aide enormement, j'ai monte une api rest sur notre backend en 15 jours recemment. Spring/jersey/jackson et j'ai un combo redoutable. Je me tape du mapping json dans tous les sens, ca va vite, c'est fiable, j'automatise le bousin avec chef tres facilement. Au final, je me retrouve avec moitie moins de VMs que ce que l'ancienne equipe .net avait, et avec de meilleurs temps de reponse et un nombre d'incidents reduits.
Les mecs qui voulaient pousser ruby sont incapables de me garantir que le format json public ne va pas changer suite a un changement innoncent de code, et l'equipe .net a toujours pas compris pourquoi du json en pascal case, ca emmerde le monde en plus de nous faire passer pour des amateurs.
Et on arrive au point ou le ruby commencerait a montrer ses probleme de perfs, et me lance pas sur son manque en multithreading (oui, je peux deployer sur des petites vm a un core, mais ca devient vite lourd).
Apres, oui, le langage a ses lourdeurs. Qu'un for(String string : list) te pete une npe a la gueule, c'est lourd. Idem avec int a = b + c, merci l'autoboxing a la con, et l'amour immodere de sun pour la philosophie "oh mon dieu! Un pointeur null! C'est la fin du monde!!".
J'ai brieffe un de mes dev objc sur cette api recemment, c'etait fun de lui dire toutes les 3 lignes "ouais, ca peut te peter une npe ca, fait gaffe". Apres, objc est le seul langage que je connaisse a etre aussi complaisant avec nil, merci le message send. Fin de la digression.
Apres, force est de constater que si tu veux faire du backend a grande echelle, ya beaucoup de chances pour qu'une evaluation objective des besoins te fasse dire "on va mettre pas mal de java la dedans".
Oui, tes data scientists vont mettre du scala, clairement tes front ends vont gueuler comme des putois (et a raison) si tu leur demande de faire du java.
Oui, java.util.Date est une blague de tres mauvais gout. Merci joda time.
Mais pour tes services, ton event bus et un paquet d'autres choses plutot critiques pour ton business, java marche bien, tres bien meme.
Ya juste trop d'historique et de boulot qui a ete accomplit en java, que ce soit dans la jvm ou l'ecosysteme pour refaire ca, et les gains seraient potentiellement limites.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par groumly . En réponse au journal Normalisation du langage Dart de Google par l'Ecma. Évalué à 1.
Bon apres, ca depend ce que tu fais aussi.
Pour du backend de consumer web de base, le langage est certe veillot, mais c'est pas la fin du monde, et les perfs sont plutot tres bonnes.
L'ecosysteme autour aide enormement, j'ai monte une api rest sur notre backend en 15 jours recemment. Spring/jersey/jackson et j'ai un combo redoutable. Je me tape du mapping json dans tous les sens, ca va vite, c'est fiable, j'automatise le bousin avec chef tres facilement. Au final, je me retrouve avec moitie moins de VMs que ce que l'ancienne equipe .net avait, et avec de meilleurs temps de reponse et un nombre d'incidents reduits.
Les mecs qui voulaient pousser ruby sont incapables de me garantir que le format json public ne va pas changer suite a un changement innoncent de code, et l'equipe .net a toujours pas compris pourquoi du json en pascal case, ca emmerde le monde en plus de nous faire passer pour des amateurs.
Et on arrive au point ou le ruby commencerait a montrer ses probleme de perfs, et me lance pas sur son manque en multithreading (oui, je peux deployer sur des petites vm a un core, mais ca devient vite lourd).
Apres, oui, le langage a ses lourdeurs. Qu'un for(String string : list) te pete une npe a la gueule, c'est lourd. Idem avec int a = b + c, merci l'autoboxing a la con, et l'amour immodere de sun pour la philosophie "oh mon dieu! Un pointeur null! C'est la fin du monde!!".
J'ai brieffe un de mes dev objc sur cette api recemment, c'etait fun de lui dire toutes les 3 lignes "ouais, ca peut te peter une npe ca, fait gaffe". Apres, objc est le seul langage que je connaisse a etre aussi complaisant avec nil, merci le message send. Fin de la digression.
Apres, force est de constater que si tu veux faire du backend a grande echelle, ya beaucoup de chances pour qu'une evaluation objective des besoins te fasse dire "on va mettre pas mal de java la dedans".
Oui, tes data scientists vont mettre du scala, clairement tes front ends vont gueuler comme des putois (et a raison) si tu leur demande de faire du java.
Oui, java.util.Date est une blague de tres mauvais gout. Merci joda time.
Mais pour tes services, ton event bus et un paquet d'autres choses plutot critiques pour ton business, java marche bien, tres bien meme.
Ya juste trop d'historique et de boulot qui a ete accomplit en java, que ce soit dans la jvm ou l'ecosysteme pour refaire ca, et les gains seraient potentiellement limites.