De temps en temps paraît un article qui prédit la mort du langage Java. Ce qui est amusant, c'est qu'aucun d'entre eux ne se hasarde à donner une date. Mais pour être honnête, ils sont tous dans le vrai. C'est là le destin de tous les langages : disparaître dans l'oubli - ou plus précisément être utilisé de moins en moins pour de nouveaux projets. La question est de savoir le langage qui les remplacera ?
La semaine dernière, un tel article a été publié sur InfoQ FR. Au moins, celui-ci a mentionné un remplaçant potentiel, Kotlin. Cela m'a permis de réfléchir à la situation et aux tendances des langages sur la JVM. Notez que les tendances n'ont rien à voir avec les points forts et faibles de chaque langage au niveau technique.
J'ai commencé à développer en Java fin 2001. À cette époque, Java était vraiment cool. Tous les jeunes développeurs voulaient travailler sur les soi-disant nouvelles technologies : soit .NET ou Java, car les développeurs plus expérimentés étaient bloqués sur Cobol. J'avais étudié le C et le C ++ à l'école et la gestion de la mémoire en Java était tellement plus facile. J'étais content avec Java... mais ce n'était pas le cas de tout le monde.
Groovy est né en 2003. Je ne me souviens pas à quel moment j'ai pris connaissance de son existence. Je l'ai simplement ignoré : je n'avais pas besoin d'un langage de script à ce moment. Dans un contexte de développement d'applications de qualité professionnelle avec une durée de vie étendue et une équipe élargie de développeurs, le typage statique était un énorme avantage par rapport au typage dynamique. Devoir créer des tests pour vérifier le typage était une perte de temps. La seule fois où j'ai du créer des scripts, c'était en tant qu'administrateur WebSphere : le choix était limité à Python et TCL.
Scala a été publié un an plus tard en 2004. Je ne me souviens pas quand et comment j'en ai entendu parler, mais c'était bien après. Contrairement à Groovy, j'ai décidé de l'essayer. La raison principale était mon intérêt pour la création d'un code "meilleur" - c'est-à-dire plus lisible et plus maintenable. Scala étant typé statiquement, il s'agissait plus de ce que je recherchais. J'ai suivi sur Coursera le cours "Principes de la programmation fonctionnelle en Scala". Cela a eu trois conséquences majeures :
- J'ai remis en cause ma manière d'écrire du code Java. Par exemple, pourquoi générer automatiquement les getters et les setters lors de la conception d'une classe ?
- J'ai décidé que Scala rendait trop aisé l'écriture d'un code illisible pour la plupart des développeurs, moi y compris.
- J'ai commencé à chercher d'autres langages alternatifs.
Après Groovy et Scala est arrivé la deuxième génération (3ème en comptant Java comme la première) des langages sur la JVM, y compris :
Après un bref regard sur chacun, j'ai été convaincu qu'ils n'avaient pas beaucoup de traction et que ça ne valait pas la peine d'investir de mon temps.
Il y a quelques années, j'ai décidé d'apprendre Android pour pouvoir comprendre le contexte de développement des développeurs mobiles. Oh, mince ! Après des années de développement d'applications Java EE et Spring, c'était une surprise - et pas des plus agréables. C'était comme être renvoyé une décennie dans le passé. L'API Android est de si bas niveau ... sans même mentionner les tests locaux. Après une recherche rapide, j'ai trouvé de nombreuses mentions de Kotlin et j'ai finalement décidé de l'essayer. Je suis tombé amoureux immédiatement : avec Kotlin, je pouvais améliorer l'API existante en quelque chose de mieux, même d'élégant, grâce aux fonctions d'extension. J'ai creusé davantage le langage et j'ai commencé à utiliser Kotlin pour les projets côté serveur. Ensuite, le framework Spring a annoncé l'intégration de Kotlin. Et à Google I/O, Google a annoncé le support de Kotlin sur Android.
Cet article porte sur ma propre expérience et mon opinion personnelle. Si vous préférez ne lire uniquement que les articles avec lesquels vous êtes d'accord, n'hésitez pas à arrêter votre lecture ici.
Outre ma propre expérience, quelle est la situation actuelle de ces langages ? J'ai effectué une recherche rapide sur Google Trends.
Il y a quelques points intéressants à noter :
- Google a reconnu les termes de recherche, c'est-à-dire "Langage de programmation" pour Scala, Groovy et Kotlin mais pas pour Ceylon et Xtend. Pour Ceylon, je suppose que c'est parce que Ceylon est un endroit populaire. Pour Xtend, je crains qu'il n'y ait pas assez de recherches Google.
- Scala est de loin le plus populaire, suivi de Groovy et Kotlin. Je n'ai aucun indice réel sur l'échelle.
- Le pic de Kotlin en mai est à mettre en corrélation avec l'annonce du support de Google à Google I/O.
- La plupart des recherches pour Scala et Kotlin proviennent de Chine, Groovy est beaucoup plus équilibré en ce qui concerne les provenances.
- Les recherches sur Scala sont fortement corrélées avec le terme "Spark", celles sur Kotlin avec le terme "Android".
En creusant un peu plus loin, on peut découvrir des faits intéressants :
- Xtend n'est pas mort, car il n'a jamais été vivant. Je n'ai jamais vu de publication à son sujet, ni jamais entendu parler d'une conférence qui le mentionne.
- En 2017, Red Hat a donné Ceylon à la fondation Eclipse, donnant naissance à Eclipse Ceylon. Le fait qu'un acteur privé donne un logiciel à une fondation peut être interprété de différentes façons. Dans ce cas particulier et malgré tous les discours rassurants autour de la migration, ce n'est pas un bon signe pour l'avenir de Ceylon.
- En 2015, Pivotal a cessé de parrainer Groovy et ce dernier a migré chez la fondation Apache. Bien que je crois que Groovy ait une communauté suffisamment large et un créneau unique pour le scripting sur la JVM, ce n'est pas non plus un bon signe. Ceci est à mettre en regard avec la fréquence de participation des principaux contributeurs de Groovy : leur nombre de commits diminue drastiquement - au point de s'arrêter pour certains.
- Il est intéressant de constater que Scala et Kotlin ont récemment envahi d'autres espaces, pouvant être transpilés vers JavaScript et compilés en natif.
- En Java, la JEP 286 est une proposition pour améliorer le langage avec l'inférence de type, une fonctionnalité déjà fournie par Scala et Kotlin. Elle est toutefois limitée aux seules variables locales.
- Il est intéressant de noter qu'il existe des initiatives pour améliorer le temps de compilation de Scala en ne conservant qu'un sous-ensemble du langage. Ce qui pose alors la question : pourquoi conserver Scala en abandonnant ses fonctionnalités les plus puissantes (telles que les macros) ?
Je ne suis pas très bon en prévisions, mais en voici quand même quelques-unes :
- Groovy a son propre créneau - le scripting, ce qui laisse Java, Scala et Kotlin rivaliser sur le segment du pur développement d'applications sur la JVM côté serveur.
- Scala a également su créer son propre espace. Les développeurs Scala considèrent généralement le langage supérieur à Java (ou Kotlin) et ne vont pas migrer vers un autre langage. Cependant, en raison des annonces de Spring et Google, Kotlin peut remplacer Scala comme langage vers lequel les développeurs se tournent quand ils ne sont pas satisfaits de Java.
- Kotlin a gagné la bataille Android. Scala a ignoré cet espace dans le passé et n'y investira pas dans le futur étant donné l'avance qu'y a acquis Kotlin.
- L'ascension de Kotlin sur le mobile n'était pas un mouvement intentionnel, mais plutôt une surprise agréable et inattendue. Mais JetBrains l'a utilisé comme levier dès qu'ils ont remarqué la tendance.
- L'inter-opérabilité de Kotlin avec Java est la fonctionnalité la plus remarquable qui peut convaincre les responsables de migrer des projets existants ou de démarrer de nouveaux projets avec Kotlin, tout comme la rétro-compatibilité l'a été pour Java.
Je serais très intéressé par votre opinion, chers lecteurs, même (surtout ?) Si vous n'êtes pas d'accord avec ce qui précède. Il suffit d'être courtois et de fournir des faits lorsque vous pouvez prouver votre point de vue.