Scala (pour Scalable Language) est un langage de programmation multiparadigme et multi-plate-forme très largement utilisé dans le domaine de l’analyse de données et notamment avec le fameux Framework Spark. Il fournit l’infrastructure de base pour des sites tels que Twitter, LinkedIn, Foursquare, Tumblr et Klout. Scala regroupe un ensemble de caractéristiques très intéressantes, entres autres, la simplicité de sa syntaxe. Ce dernier peut en effet être vu comme un métalangage.Il intègre aussi le paradigme de programmation orientée objet et de programmation fonctionnelle, ce qui permet de tirer profit des avantages de ces deux paradigmes complémentaires. En plus de tout cela, Scala est compilé en bytecode Java, il est alors possible d’utiliser les bibliothèques écrites en Java d’une manière complètement transparente. Cela permet à Scala de tirer profit de la grande maturité et la diversité des bibliothèques qui ont fait la force du langage Java depuis plusieurs années. De plus, il est possible d’invoquer du code écrit en Scala à partir de programmes écrits en Java ce qui facilite la transition de Java à Scala.
L'équipe responsable de son développement a annoncé la feuille de route de la version Scala 3 :
« En collaboration avec l'équipe Scala 3 de l'EPFL (alias l'équipe Dotty), dirigée par Martin Odersky, nous avons décidé que, plutôt que de développer Scala 2.14, nos efforts devraient plutôt aller à Scala 3. Bien que nous soyons très heureux de nous concentrer sur Scala 3, nous continuerons à maintenir Scala 2.13 pour garantir à la communauté suffisamment de temps pour passer soigneusement à Scala 3. Nous pensions depuis longtemps qu’une version 2.14 serait nécessaire pour assurer une transition en douceur vers 3. Après de nombreuses études et discussions, nous sommes maintenant convaincus que la version 2.14 n’est tout simplement pas nécessaire. Nous pensons que c'est une bonne nouvelle pour tout le monde ! »
Les bénéfices évoqués sont :
- Scala 3 sera prêt pour une production plus rapide! L'équipe note qu'il y a beaucoup de travail à faire pour polir le compilateur et mettre à jour ses outils. Elle rappelle qu'elle va aider également à la mise à niveau de l'écosystème.
- La bibliothèque Scala et l'écosystème d'outils n'auront pas besoin d'être reconstruits pour la version 2.14, libérant ainsi du temps pour les responsables de la préparation pour Scala 3.
« Notre objectif principal est de fournir un chemin de migration fluide et incrémentiel de Scala 2 vers 3. Pour ce faire, Scala 2.13 et 3.0 utiliseront la même bibliothèque standard, et leurs serveurs de compilation compileront le bytecode de la même manière ».
Scala a été le pionnier de la fusion de la programmation orientée objet et fonctionnelle dans un environnement typé. Scala 3 sera un grand pas vers la réalisation du plein potentiel de ces idées. La nouvelle version du langage aura pour objectifs d'éliminer les incohérences, de consolider les constructions linguistiques pour améliorer la cohérence, la sécurité, l'ergonomie et la performance du langage. Aussi, à la différence de la version 2, le compilateur Dotty sera doté du support LSP (Language Server Protocol).
Scala 3 et Scala 2 partagent la même bibliothèque standard, le code Scala 3 peut utiliser des artefacts Scala 2, car Scala 3 comprend le format de fichier de classe pour les sources compilées avec Scala 2.12 et plus. Scala 3 dispose d'une option -language:Scala2 qui permet de compiler la plupart des codes Scala 2 et met en évidence les réécritures nécessaires en tant qu'alertes de migration et l'option -rewrite pour l'exécution de plusieurs réécritures automatiquement.
ABI partagé
En partageant également l'ABI (Application Binary Interface, c'est-à-dire la façon dont les traits, les valeurs paresseuses, etc. sont représentés dans le bytecode et l'IR de Scala.js/Native), les artefacts Scala 3.0 et 2.13 peuvent coexister sur le chemin de classe et interagir de manière transparente. Cela permet une migration progressive et simplifie les tests.
Scala 3 est déjà rétrocompatible aujourd'hui : il peut se servir de bibliothèques construites avec Scala 2.13 (sauf pour les bibliothèques qui définissent des macros). Pour obtenir une compatibilité ascendante, le compilateur Scala 3 fournira un mécanisme pour garantir que l'interface publique est dans le sous-ensemble de langage commun, afin qu'elle puisse être utilisée à partir de Scala 2.13. Cela signifie qu'en tant qu'auteur de bibliothèque, vous pouvez adopter (une partie de) Scala 3 sans exiger de vos utilisateurs une mise à niveau de Scala 2.13.
Outre l'interopérabilité technique, l'équipe va investir dans les tests et améliorer l'outillage pour assurer une migration en douceur. Par exemple, les avertissements de migration initialement prévus pour 2.14 seront implémentés dans 2.13. Elle n'exclut pas de rétroporter certaines fonctionnalités de Scala 3 vers 2.13 sous un drapeau, mais ce ne sera pas une priorité.
Quand Scala 3.0 sera-t-il disponible ?
L'équipe travaille sur une première Release Candidate qui devra être publiée d'ici la fin de 2020. « Nous aurons des jalons réguliers tout au long de l'année. Vos commentaires et notre expérience dans les tests, l'analyse comparative et l'aide au portage de l'écosystème guideront la décision quant au moment de supprimer la première version candidate. Nous vous tiendrons informés pendant que nous affinerons le calendrier de sortie ».
Comment la bibliothèque standard va-t-elle évoluer?
Scala 3.0 utilisera la même bibliothèque standard que Scala 2.13.x, le même binaire JAR. Cela simplifie la migration vers Scala 3 en évitant toute une zone de différences potentielles et permet aux artefacts Scala 3.0 et 2.13 de coexister sur le chemin de classe.
Comme toute version de Scala 2, la bibliothèque standard de Scala 2.13 est, et restera, compatible binaire en amont et en aval. Cela limite les modifications pouvant être effectuées: aucune classe ou méthode publique ne peut être ajoutée ou supprimée. (La compatibilité descendante empêche les suppressions; la compatibilité ascendante empêche les ajouts). L'équipe pourrait éventuellement choisir de publier un Scala 2.14, si pendant la période de migration de Scala 2 à 3, il y a un besoin impérieux d'évoluer la bibliothèque standard en dehors de ces contraintes.
Néanmoins, il est possible d'implémenter des améliorations significatives dans l'implémentation des classes existantes tout en restant compatible binaire. Par exemple, il existe un Pull Request avec une réécriture complète de collection.immutable.Vector compatible binaire. Actuellement, l'ajout de remplacements dans la bibliothèque de collections entraîne souvent des incompatibilités binaires, mais il existe une proposition pour résoudre ce problème.
L'utilisation de la bibliothèque standard Scala 2.13 n'est qu'un point de départ. Elle ne s'applique pas à l'ensemble de la série Scala 3.x. Une version ultérieure de Scala 3, peut-être 3.2, sera livrée avec sa propre bibliothèque standard. À partir de ce moment, les versions de Scala 3.x ne seront plus rétrocompatibles. Cela permettra d'ajouter de nouvelles classes et méthodes dans les versions mineures. Même avant cela, il est possible de publier des extensions de la bibliothèque 2.13 en 3.0 ou 3.1. Les bibliothèques utilisant ces extensions seraient réservées aux utilisateurs de Scala 3.
Chaque bibliothèque compilée avec Scala 3 inclut TASTy, qui permet de faire le pont entre les changements d'encodage binaire entre les versions mineures. Cela permet au code compilé avec l'éventuelle bibliothèque standard Scala 3 de fonctionner avec tout nouveau Scala 3.x. Cela améliore la maintenabilité de la bibliothèque standard. Au lieu d'exiger la compatibilité binaire (qui dépend des détails d'encodage du bytecode), les modifications apportées aux classes existantes doivent uniquement être compatibles avec l'API TASTy.
Tout changement sémantique et structurel de la bibliothèque standard doit attendre Scala 4. Les nouvelles versions majeures deviendront plus fréquentes, principalement en raison des améliorations apportées à la bibliothèque standard qui ne peuvent pas être implémentées de manière rétrocompatible.
Qu'est-ce que TASTy?
Le compilateur Scala 3 sérialise chaque programme qu'il compile dans une représentation compacte appelée TASTy. Le nom TASTy signifie «Typed Abstract Syntax Trees (y)», qui fait allusion au format de représentation: c'est le code de programme complet sous forme d'arbres de syntaxe, qui est ce que le compilateur utilise en interne, et il est entièrement typé. Cela signifie que les noms sont résolus, les types sont inférés et vérifiés, les surcharges sont résolues et les implications sont insérées. Toutes ces informations sont sérialisées.
Aujourd'hui, TASTy est utilisé pour une compilation séparée: lorsqu'un fichier source utilise Foo.method où Foo est une classe sur le chemin de classe, le compilateur lira le TASTy de Foo afin de savoir quel est le type de méthode. L'examen du fichier de classe Foo.class ne fonctionnerait pas, car les fonctionnalités spécifiques à Scala telles que les types d'union ne peuvent pas être représentées dans les fichiers de classe. Scala 2 utilise un mécanisme très similaire, mais au lieu de sérialiser le code de programme complet, il ne sérialise que les types, ce qui est suffisant pour une compilation séparée.
À l'avenir, TASTy atténuera les incompatibilités binaires «accidentelles» causées par la façon dont les fonctionnalités spécifiques à Scala doivent être codées dans les fichiers de classe JVM. Étant donné que TASTy capture précisément le résultat du frontend (après que le vérificateur de type a pleinement qualifié tous les noms, les types inférés, résolu les surcharges, etc.), le backend du compilateur Scala peut être réexécuté automatiquement pour dériver de nouveaux fichiers de classe de TASTy sérialisés par une exécution précédente. C’est un compromis prometteur entre la fragilité du bytecode et la complexité de la recompilation à partir de la source.
TASTy servira également de base pour des outils nouveaux ou mises à jour à l'avenir (analyse de code, support IDE, génération de documentation).
Et les macros?
Alors que Scala 3 peut généralement utiliser des bibliothèques construites avec Scala 2.13, cela ne fonctionne pas pour les macros. Les méthodes de macro définies dans les bibliothèques 2.13 ne peuvent pas être utilisées dans Scala 3, car le compilateur Scala 3 ne peut pas exécuter la macro au moment de la compilation.
Le système macro de Scala 2 est profondément lié aux composants internes du compilateur Scala 2 et ne peut pas être migré de manière compatible vers Scala 3. Au lieu de cela, Scala 3 est livré avec un nouveau système macro. Cela signifie que les définitions de macro doivent être réécrites lors de la migration d'une base de code vers Scala 3. La création croisée est possible en ayant des fichiers source séparés pour les définitions de macro Scala 2 et 3.
Les bibliothèques qui définissent les macros peuvent être rendues disponibles pour Scala 2.13 et Scala 3 par compilation croisée.
Source : feuille de route Scala 3
Voir aussi :
Scala Native disponible en version 0.3.9, le développement du générateur de code natif pour accéder au bas niveau depuis le langage Scala se poursuit La version 2.13 du langage Scala est disponible avec une refonte des collections et des améliorations de la bibliothèque standard Kotlin gagne trois places et dépasse Scala dans le classement PYPL, l'indice qui analyse la fréquence de recherche des tutoriels sur Google