Nos réponses aux 10 questions les plus posées sur l’avenir de Kotlin
Dans cet article, vous trouverez les réponses à 10 des questions les plus fréquentes sur l’avenir de Kotlin. Vous pouvez aussi rejoindre les discussions dans les commentaires ou sur Reddit (liens ci-dessous) !
Dans le cadre de l’annonce de la version 1.5.0, nous avons organisé une session Ask Me Anything avec l’équipe Kotlin sur Reddit. A cette occasion, nous avons reçu des centaines de questions.
En parcourant les questions sur Reddit, nous nous sommes dit qu’il serait utile de partager les réponses plus largement auprès des membres de la communauté Kotlin. Un grand merci à tous ceux qui ont posé des questions et à l’équipe qui a pris soin de répondre à chacune d’elles.
Nous avons reçu de nombreuses questions techniques, ainsi que des questions sur la dernière version. Mais les questions les plus populaires, qui étaient aussi celles que nous avons trouvé les plus intéressantes, concernaient l’avenir de Kotlin.
Questions
Question #1
Il y a quelques années, une enquête auprès des développeurs nous a permis de voter pour les fonctionnalités que nous attendions le plus. Envisager vous de réitérer ce type d’initiative à l’avenir ?
« Mise à jour : L’enquête est disponible. Les descriptions des fonctionnalités et l’enregistrement du webinaire de Svetlana Isakova et Roman Elizarov se trouvent dans cet article de blog. Oui, nous travaillons actuellement sur la prochaine édition de cette enquête. Restez à l’écoute ! »
Le thread sur Reddit
Question #2
Sur du moyen à long terme, disons environ 5 ans, étant donné que le rythme des changements pour Java s’est accéléré, envisagez-vous d’éventuelles difficultés à maintenir la compatibilité de Kotlin avec Java ? Par exemple, y a-t-il actuellement des projets de modification du langage Java ou de la structure du bytecode de la JVM avec lesquels il serait très difficile d’intégrer Kotlin ?
« Nous suivons attentivement le processus de conception de la JVM et nous ne nous ne pensons pas rencontrer de problèmes avec les fonctionnalités de la JVM en cours de développement, ni même avec celles prévues dans un avenir plus lointain. »
Le thread sur Reddit
Question #3
J’ai posé cette question la dernière fois mais quelle est votre opinion actuelle sur la reconnaissance de schémas ?
« Nous nous y intéressons, mais nous pensons que l’amélioration la plus importante à apporter à court terme pour les expressions when de Kotlin est la prise en charge des gardes. Voir https://youtrack.jetbrains.com/issue/KT-13626 ».
Le thread sur Reddit
Question #4
Y aura-t-il un moyen que Kotlin soit compilé en Swift plutôt qu’en Objective-C pour KMM ?
« Kotlin n’est en fait pas compilé en Objective-C pour iOS.
Au lieu de cela, à la base, Kotlin/Native compile Kotlin directement en code natif (à l’aide de LLVM).
De plus, il génère des ponts pour rendre le code Kotlin compilé accessible à partir de d’Objective-C et de Swift. Pour une classe en Kotlin Foo, le compilateur génère en plus un “adaptateur” qu’Objective-C et Swift perçoit comme une classe en Objective-C. Cet adaptateur délègue tout à la classe d’origine en Kotlin.
C’est plutôt comme si le compilateur Kotlin/Native ajoutait une représentation en Objective-C pour l’API Kotlin. La question est donc en fait : y aura-t-il un moyen pour Kotlin d’ajouter une représentation en Swift ? Et la réponse est : oui, nous l’envisageons. »
Plus d’informations sur Reddit
Question #5
Est-il prévu d’extraire la fonctionnalité de mise en forme d’IntelliJ [IntelliJ IDEA] vers un outil distinct ?
« Nous sommes sur le point de terminer notre travail sur un vérificateur de règles de mise en forme qui pourra s’exécuter en intégration continue. Il sera basé sur Qodana et démarrera une inspection qu’IntelliJ IDEA a déjà pour Kotlin.
Actuellement :
- Cette inspection est trop dépendante des paramètres de mise en forme d’IntelliJ IDEA qui sont stockés dans le dossier .idea.
- Elle n’est actuellement pas très informative : elle indique simplement que la mise en forme est erronée.
Nous espérons corriger ces deux problèmes et ajouter l’inspection à Qodana. »
Plus d’informations sur Reddit
Question #6
Vous avez précédemment annoncé que la vitesse de compilation serait la principale priorité de l’équipe Kotlin, mais qu’il s’agirait d’un travail de nombreuses années s’étalant sur plusieurs versions. Avez-vous de nouvelles informations sur la façon dont les choses se présentent ?
« Notre travail sur les performances de la compilation se divise en deux parties :
- L’écriture d’un nouveau front-end pour le compilateur, l’objectif principal étant d’obtenir de bien meilleures performances qu’avec l’existant.
- L’optimisation du nouveau back-end du compilateur (back-end IR) après sa sortie et la résolution des bugs les plus critiques.
Le back-end JVM/IR ayant été publié avec Kotlin 1.5, notre équipe JVM se concentrera donc sur ses performances dans un futur proche.
En parallèle, nous développons activement le nouveau front-end, dont nous voulons publier une première version cet automne. Le nouveau front-end du compilateur sera à l’origine du principal gain de performances. Pour le moment, il est 4 fois plus rapide que le front-end actuel, ce qui en réalité double la vitesse de la totalité de la compilation (front-end + back-end).
De plus, le plugin Kotlin pour l’IDE utilisant un plugin du compilateur pour l’analyse, un nouveau plugin basé sur FIR améliorera également les performances de l’expérience d’utilisation de l’IDE. »
Le thread sur Reddit
Question #7
Prévoyez-vous de fournir une solution Kotlin DI [Dependency Injection] nativement ?
« Nous pensons que la DI [Dependency Injection] fonctionne mieux en tant que bibliothèque séparée, car elle crée de trop nombreuses demandes concurrentes pour être un jour intégrée dans le langage ou même dans sa bibliothèque standard. »
Plus d’informations sur Reddit
Question #8
Que pense l’équipe Kotlin de l’idée d’un compilateur croisé Kotlin / TypeScript ? De la même façon que Kotlin et Java, qui peuvent être compilés ensemble.
« Nous sommes tout à fait d’accord pour dire qu’une telle interopérabilité avec JS/TS serait une bonne idée, mais cela constitue un défi important pour les raisons suivantes :
- Les systèmes de type Kotlin et TS/JS et leur sémantique sont incompatibles.
- TS évolue très rapidement.
- Nous devrions trouver un moyen d’intégrer dans les deux sens (!) : un compilateur TS écrit en TS et ciblant la machine virtuelle JS comme environnement d’exécution, ainsi qu’un compilateur Kotlin écrit en Kotlin et Java ciblant la JVM comme environnement d’exécution. Nous pourrions aussi écrire et prendre en charge notre propre front-end de compilateur TS
(C’est beaucoup plus simple pour Java – nous réutilisons simplement le front-end du compilateur Java d’IntelliJ)
C’est pourquoi, pour l’instant, nous nous concentrons sur une interopérabilité séparée en plusieurs étapes – la consommation des déclarations TS (d.ts) en les convertissant en déclarations Kotlin, puis la génération des déclarations TS (d.ts) depuis Kotlin. Notez que la génération des déclarations TS (d.ts) depuis Kotlin n’est disponible qu’avec le nouveau back-end JS IR du compilateur.
Qui sait, cela sera peut-être un jour aussi fluide, ce que nous aimerions tous ;) »
Plus d’informations sur Reddit
Question #9
Quelle est la prochaine étape concernant Kotlin et Spring, sur le plan Kotlin côté serveur ?
« Spring Boot 2.5 vient d’être publiée, avec Kotlin 1.5 avec pour base et les mises à jour des bibliothèques Coroutines 1.5 et Serialization 1.2.
Nos prochaines étapes seront de fournir une bonne prise en charge de Kotlin/JVM/Native (Native avec Kotlin/JVM via les images natives GraalVM) grâce à https://github.com/spring-projects-experimental/spring-native/, l’amélioration du développement multiplateforme (avec le front-end Kotlin/JS par exemple), l’adaptation de la documentation de Spring Boot à Kotlin (grâce à une contribution de l’équipe Kotlin), et de nous assurer que les APIs ne fonctionnant actuellement pas avec Kotlin à cause de quelques bugs d’inférence de type avec les types génériques récursifs (comme WebTestClient) deviennent utilisables.
Sur le long terme, mes sujets préférés sont se débarrasser de kotlin-reflect lors de l’exécution dans le framework Spring en effectuant la réflexion de Kotlin en amont et en continuant à mûrir https://github.com/spring-projects-experimental/spring-fu une manière plus DSL de configurer Spring Boot.
Même si ce n’est pas une implémentation basée sur Spring, nous aimerions aider https://github.com/rsocket/rsocket-kotlin, qui est une très bonne implémentation en Kotlin multiplateforme de protocole RSocket (https://rsocket.io/ peut être une alternative à GRPC dans de nombreux cas d’utilisation) mature »
Plus d’informations sur Reddit
Question #10
Il était prévu de fournir des capacités de métaprogrammation – des nouvelles sur le sujet ?
« Nous travaillons sur la métaprogrammation à deux égards :
- Les plugins de compilateur – nous voyons de nombreuses mises à jour de la communauté dans ce domaine. Découvrez par exemple l’excellente série de Brian Norman : https://bnorm.medium.com/writing-your-second-kotlin-compiler-plugin-part-1-project-setup-7b05c7d93f6c. À l’avenir, nous prévoyons de fournir une API de compilateur stable pour ces types de plugins.
- Meilleurs inlining et évaluation des expressions constantes – restez à l’écoute des mises à jour sur ces points. Il y a des chances que nous puissions montrer un aperçu du développement de ces recherches cette année. »
Le thread sur Reddit
Plus de ressources utiles sur Kotlin et son avenir
- Publication de Kotlin 1.5.0 : article de blog et vidéos
- Points clés de la feuille de route de Kotlin
- Informations sur l’événement Kotlin 1.5 et questions les plus populaires de la sessions de Questions&Réponses
- Rejoignez le subreddit Kotlin pour les futures sessions AMA avec l’équipe.
Abonnez-vous à notre compte Twitter, aux mises à jour du blog et à la chaîne YouTube pour les futures annonces. Nous ouvrirons bientôt le vote pour les nouvelles fonctionnalités de Kotlin et nous avons hâte de connaître votre avis sur ce que nous devrions prioriser !
Auteur de l’article original en anglais :
Subscribe to Kotlin Blog updates
