Pourtant la JVM défonce à peu près tout le monde niveau perfs
Je ne te parle pas de la JVM.
Si tu regardes les évolutions du langage la majorité écrivent juste le boilerplate, que tu n'aurais jamais du avoir à écrire, pour toi. Les concepts restes les mêmes on les masque juste et c'est javac qui pisse du bytecode pour toi.
Bref c'est cool on arrête d'avoir à écrire des stupidités, ca va réduire le nombre de lignes de code inutile mais des vrais progrès tu en as très peu que ce soit en expressivité, en perf ou en fiabilité. Le langage a beau être simple il est piégeur dans la vraie vie.
Maintenant la complexité d'implémentation le dev ne la voit pas. Mais si tu t'interesse un poil au travail dans OpenJDK tu verras que ca devient de plus en plus difficile pour rajouter quelque chose dans le langage. Et ca ne présage rien de bon pour l'avenir.
Pour les perfs de la JVM, c'est un excellent compromis si tu n'as pas besoin du SIMD ni d'auto-vectorisation. C'est actuellement l'un de ses plus gros points faibles par rapport à du C/C++. Tout le monde n'en a pas besoin mais quand tu tombes dessus ca fait mal. Après selon tes besoins tu vas coder en Java idiomatique ou en C-like si tu as besoin d'aller vite où d'avoir de faible latence (finance, db, big data).
jamais eu autant de libs (le JDK on s'en fout, tout se fait via Maven)
Non on ne s'en fou pas. Il y a des choses qui doivent être au coeur du langage sinon elles perdent leur intêret. Si part hasard elles finissent par trouver leur chemin dans le JDK alors tu traines ce clash pendant des années.
Prenons Optional de Java 8. Java est une pourriture concernant la null-safety depuis le début.
Guava a rajouté l'Optional comme sucre syntaxique. C'est cool on peut commencer à l'utiliser, c'est toujours pas null-safe (un Optional peut être null) mais au moins c'est expressif. Si je veux l'utiliser je dois ajouter une dépendence vers Guava. Maintenant ca fait sont chemin vers le JDK. Maintenant j'ai deux implémentations concurrentes et incompatible. Si je bascule sur le JDK je pète la compat de mon projet. Si je reste sur Guava alors je vais imposer de plus en plus de conflit à mes utilisateurs. Ooops. C'est un problème très courant quand des libs font le job de ce qui devrait être dans le JDK. Et ca fini toujours en bordel crado.
Maintenant on a rajouté Optional mais comme on va pas changer l'API du JDK bin j'ai 50% des méthodes du JDK qui peuvent toujours retourner null. Donc je fini aussi avec un truc ultra-batard
C'est un exemple parmis des dizaines d'autres. De même avoir un langage expressif à la base permet d'avoir du code cohérent et fiable. Regarde les milliers de pauvres dev Java se débattre avec la composition de future et tu pleures. Ce genre de trou fait très très mal et c'est en parti un problème du langage et du JDK.
On peut regretter le poids de l'historique et la bloat attitude, mais quelle plateforme de dev peut aujourd'hui prétendre à ce niveau?
Aucune. Ne lis pas ce que je dis comme une critique bête et méchante de Java ce n'est pas le cas. Je signalais que tout n'est pas rose ainsi que les problèmes qui arrivent.
Ca fait quelques années que pas mal de gens cherchent à avancer et construire un nouveau langage sur la JVM et c'est chaud à cause de l'interop Java (autrement l'interet de la JVM diminue fortement). Pendant ce temps là on continue d'écrire les core-lib en Java comme on écrirait du C, des bindings Scala/Groovy/Whatever et on prend son mal en patience en ayant l'impression d'être toujours aussi mal chaussé et le cul entre deux chaises depuis 10-15 ans même si c'est clairement la meilleure plateforme pour beaucoup de trucs.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par ckyl . En réponse au journal Normalisation du langage Dart de Google par l'Ecma. Évalué à 5.
Je ne te parle pas de la JVM.
Si tu regardes les évolutions du langage la majorité écrivent juste le boilerplate, que tu n'aurais jamais du avoir à écrire, pour toi. Les concepts restes les mêmes on les masque juste et c'est javac qui pisse du bytecode pour toi.
Bref c'est cool on arrête d'avoir à écrire des stupidités, ca va réduire le nombre de lignes de code inutile mais des vrais progrès tu en as très peu que ce soit en expressivité, en perf ou en fiabilité. Le langage a beau être simple il est piégeur dans la vraie vie.
Maintenant la complexité d'implémentation le dev ne la voit pas. Mais si tu t'interesse un poil au travail dans OpenJDK tu verras que ca devient de plus en plus difficile pour rajouter quelque chose dans le langage. Et ca ne présage rien de bon pour l'avenir.
Pour les perfs de la JVM, c'est un excellent compromis si tu n'as pas besoin du SIMD ni d'auto-vectorisation. C'est actuellement l'un de ses plus gros points faibles par rapport à du C/C++. Tout le monde n'en a pas besoin mais quand tu tombes dessus ca fait mal. Après selon tes besoins tu vas coder en Java idiomatique ou en C-like si tu as besoin d'aller vite où d'avoir de faible latence (finance, db, big data).
Non on ne s'en fou pas. Il y a des choses qui doivent être au coeur du langage sinon elles perdent leur intêret. Si part hasard elles finissent par trouver leur chemin dans le JDK alors tu traines ce clash pendant des années.
Prenons Optional de Java 8. Java est une pourriture concernant la null-safety depuis le début.
Guava a rajouté l'Optional comme sucre syntaxique. C'est cool on peut commencer à l'utiliser, c'est toujours pas null-safe (un Optional peut être null) mais au moins c'est expressif. Si je veux l'utiliser je dois ajouter une dépendence vers Guava. Maintenant ca fait sont chemin vers le JDK. Maintenant j'ai deux implémentations concurrentes et incompatible. Si je bascule sur le JDK je pète la compat de mon projet. Si je reste sur Guava alors je vais imposer de plus en plus de conflit à mes utilisateurs. Ooops. C'est un problème très courant quand des libs font le job de ce qui devrait être dans le JDK. Et ca fini toujours en bordel crado.
Maintenant on a rajouté Optional mais comme on va pas changer l'API du JDK bin j'ai 50% des méthodes du JDK qui peuvent toujours retourner null. Donc je fini aussi avec un truc ultra-batard
C'est un exemple parmis des dizaines d'autres. De même avoir un langage expressif à la base permet d'avoir du code cohérent et fiable. Regarde les milliers de pauvres dev Java se débattre avec la composition de future et tu pleures. Ce genre de trou fait très très mal et c'est en parti un problème du langage et du JDK.
Aucune. Ne lis pas ce que je dis comme une critique bête et méchante de Java ce n'est pas le cas. Je signalais que tout n'est pas rose ainsi que les problèmes qui arrivent.
Ca fait quelques années que pas mal de gens cherchent à avancer et construire un nouveau langage sur la JVM et c'est chaud à cause de l'interop Java (autrement l'interet de la JVM diminue fortement). Pendant ce temps là on continue d'écrire les core-lib en Java comme on écrirait du C, des bindings Scala/Groovy/Whatever et on prend son mal en patience en ayant l'impression d'être toujours aussi mal chaussé et le cul entre deux chaises depuis 10-15 ans même si c'est clairement la meilleure plateforme pour beaucoup de trucs.