Elixir tire parti de la machine virtuelle Erlang, connue pour l’exécution de systèmes distribués et tolérants aux pannes à faible temps de latence, tout en étant utilisé avec succès dans les domaines du développement Web et des logiciels embarqués. L’équipe d’Elixir a indiqué que la fonctionnalité la plus importante de la version 1.9 est la prise en charge des “releases”. Une “release” est un « répertoire autonome » qui encapsule non seulement le code de votre application et ses dépendances, mais également l'ensemble de la machine virtuelle Erlang et de son exécution.
Autrement dire, les “releases” permettent aux développeurs de précompiler et de conditionner la totalité de leur code et de l'exécution en une seule unité. Une fois qu'une édition est assemblée, elle peut être empaquetée et déployée sur une cible à condition que celle-ci s'exécute sur la même distribution et la même version du système d'exploitation que la machine exécutant la commande « mix release ». Voici quelques caractéristiques des “releases” :
- préchargement du code : la machine virtuelle dispose de deux mécanismes pour charger le code, interactif et intégré. Par défaut, il s'exécute en mode interactif, qui charge dynamiquement les modules lors de leur première utilisation. Lors du premier appel de votre application Enum.map/2, la machine virtuelle trouvera le module Enum et le chargera. Lorsque vous démarrez un nouveau serveur en production, il peut être nécessaire de charger de nombreux autres modules, ce qui entraînera un pic inhabituel dans le temps de réponse des premières demandes. Les “releases” s'exécutent en mode intégré, ce qui charge tous les modules disponibles à l'avance, garantissant que votre système est prêt à gérer les demandes après le démarrage ;
- configuration et personnalisation : les “releases” permettent aux développeurs de contrôler avec précision la configuration du système et les indicateurs de machine virtuelle utilisés pour démarrer le système ;
- autonome : une “release” ne nécessite pas que le code source soit inclus dans vos artefacts de production. Tout le code est précompilé et empaqueté. Les “releases” ne nécessitent même pas Erlang ou Elixir sur vos serveurs, car elles incluent la machine virtuelle Erlang et son environnement d’exécution par défaut. En outre, les bibliothèques standard d'Erlang et d'Elixir sont supprimées pour ne contenir que les composants que vous utilisez réellement ;
- plusieurs “releases” : vous pouvez assembler différentes “releases” avec différentes configurations par application ou même avec différentes applications ;
- scripts de gestion : les “releases” incluent des scripts pour démarrer, redémarrer, se connecter au système en cours d’exécution, exécuter des appels RPC, s’exécuter en tant que démon, s’exécuter en tant que service Windows, etc.
La seconde fonctionnalité mise en avant dans cette version d’Elixir est l’intégration d’une nouvelle API de configuration simplifiée sous la forme d’un nouveau module appelé “Config”. L'API de configuration précédente Mix.Config faisait partie de l'outil de génération Mix. Selon les développeurs du langage, à partir d’Elixir 1.9, la configuration du runtime est maintenant prise en charge par les “releases” et Mix n'est plus inclus dans les “releases”, cette API est maintenant portée vers Elixir. En d'autres termes, « use Mix.Config » est obsolète en faveur de « import Config ».
Un autre changement important lié à la configuration est que la directive « mix new » ne générera plus de fichier « config/config.exs ». S'appuyer sur la configuration n'est pas souhaitable pour la plupart des bibliothèques et les fichiers de configuration générés ont poussé les auteurs de bibliothèques dans la mauvaise direction. En outre, « mix new--umbrella » ne générera pas plus de configuration pour chaque application enfant, mais toute configuration devrait être déclarée dans la racine. Cela a toujours été le cas, le processus est juste rendu plus explicite avec la nouvelle configuration.
Elixir v1.9 comporte également de nombreuses autres améliorations. L'Elixir CLI dispose d'une poignée de nouvelles options afin de mieux prendre en charge les “releases”. « Logger » calcule maintenant ses seuils sync/async/discard de manière décentralisée, réduisant ainsi les conflits. Les modèles EEx (Embedded Elixir) prennent en charge des expressions plus complexes qu'auparavant. Enfin, l’équipe a indiqué que les “releases” constituent la dernière fonctionnalité planifiée pour être intégrée dans Elixir. Ainsi, l’équipe ne prévoit pas d’ajouter d’autres fonctionnalités pour les utilisateurs dans un avenir proche. Elixir arrive-t-il à sa dernière version ?
L’équipe a répondu que non, car Elixir continuera à recevoir des mises à jour de correctifs, ainsi que des améliorations pour certaines fonctionnalités. « Bien sûr, cela ne signifie pas que la version 1.9 est la dernière version d'Elixir. Nous continuerons à envoyer de nouvelles versions tous les 6 mois avec des améliorations, des corrections de bugs et des améliorations », a-t-elle déclaré. Elle a également indiqué être en train de travailler sur des changements structurels.
L'une d'elles consiste à déplacer la directive « mix xref » directement dans le compilateur, ce qui permettrait d'émettre des avertissements de fonction non définis et des avertissements de dépréciation dans davantage d'endroits. Elle envisage également de migrer vers « Cirrus-CI » afin de pouvoir tester Elixir sous Windows, Unix et FreeBSD via un seul service. Dans la communauté, les développeurs semblent enthousiasmés par l’apparition des « releases ». « Même sans la compilation et la configuration, il est plus facile de placer le paquet des “releases” dans quelque chose de basique, comme une image alpine, au lieu de synchroniser les versions d’image de docker et les applications », a déclaré l’un d’entre eux. Selon un autre, avec la sortie d'Elixir 1.9, il n'y a jamais eu de meilleur moment pour commencer l’apprentissage du langage.
Source : Elixir
Et vous ?
Qu'en pensez-vous ?
Voir aussi
Le langage de programmation V vient d'être publié en open source et semble ne pas tenir toutes ses promesses
Quel langage de programmation comporte le plus de vulnérabilités en matière de sécurité ? Une étude de WhiteSource
Android : Kotlin est désormais le langage préféré et recommandé par Google,vers la fin de Java pour le développement Android ?