Unison est conçu pour offrir un support spécial pour la construction de systèmes distribués. Il est motivé par l'idée que la technologie de création de logiciels doit être conçue de manière réfléchie dans tous ses aspects. Les complexités doivent être supprimées. Paul Chiusano, l'un des principaux développeurs du langage, a déclaré qu'Unison était un projet de recherche dans le cadre duquel ils étaient prêts à repenser le fonctionnement de la programmation. Encore au stade expérimental, Unison est un langage de programmation fonctionnelle typée statiquement, similaire à Haskell, qui offre les possibilités suivantes :
- la possibilité de décrire des systèmes distribués ;
- gestion simplifiée de la base de code : Unison utilise une base de données de définitions qui conserve le hash de l'arbre syntaxique au lieu de la source réelle ;
- mise en cache des résultats des tests ;
- élimination les conflits de dépendances
- typage persistant et stockage simple ;
- renommage trivial.
Les définitions dans Unison sont identifiées par leur contenu, chaque définition constituant un arbre syntaxique. En hachant l'arbre d'une manière qui incorpore les hashs des dépendances de la définition, le hash d'Unison identifie de manière unique cette définition. Selon l'équipe de développement d'Unison, cette fonctionnalité est destinée à servir de base à de sérieuses améliorations de l'expérience de programmation, en éliminant les constructions et la plupart des conflits de dépendances et en permettant un déploiement facile du code et un stockage durable typé.
Pour la refactorisation, Unison offre un processus structuré dans lequel une nouvelle version compilable du code est construite de manière incrémentielle sur le côté, offrant des avantages tels qu'une base de code qui est toujours exécutable et jamais cassée, éliminant le besoin de mettre à jour une base de code entière. La fonction Remote.Transfer du langage fournit un "effet à distance" qui facilite le calcul sur plusieurs nœuds Unison. Le transfert dynamique de calculs arbitraires est possible, car les définitions dans Unison sont identifiées par un hachage cryptographique de leur contenu.
Lorsque les calculs sont transférés, le nœud destinataire vérifie si le contenu fait référence à des hashs inconnus. Les hashs inconnus sont synchronisés avec le destinataire avant que le transfert ne soit terminé et que le calcul ne se poursuive. « Cette hypothèse de départ offre des avantages surprenants : elle simplifie la programmation distribuée, élimine les constructions et les conflits de dépendances, prend en charge le stockage durable typé, les refactorisations structurées, permet de meilleurs outils pour travailler avec le code, et bien plus encore », a écrit l'équipe dans un billet de blogue.
Voici un exemple d'implémentation distribuée de MapReduce :
Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 | -- comments start with `--` mapReduce loc fn ifEmpty reduce data = match split data with Empty -> ifEmpty One a -> fn a Two left right -> fl = forkAt loc '(mapReduce loc fn ifEmpty reduce !left) fr = forkAt loc '(mapReduce loc fn ifEmpty reduce !right) reduce (await fl) (await fr) |
Cette fonction peut être soit simulée localement (éventuellement avec des fautes injectées à des fins de test), soit exécutée sur un pool de calcul distribué. Bien que certains semblent enthousiasmés par l'approche proposée par Unison, elle fait néanmoins l'objet de quelques critiques. Certains critiquent la façon dont le projet est mené. « Je pense qu'ils font une erreur fréquente dans ce genre de projet : "essayer trop de nouvelles choses à la fois". Ils ont déjà une façon très innovante de gérer le code source, avec une base de données de définitions qui conserve le hash de l'arbre syntaxique au lieu de la source réelle », commente un critique.
« C'est une idée très intéressante qui résout de nombreux problèmes. La meilleure chose aurait été de développer cette idée suffisamment bien pour qu'elle fonctionne avec des outils de contrôle de source, des EDI et qu'elle puisse être déployée facilement et sans douleur sur l'infrastructure existante. Mais ils ont décidé de résoudre aussi l'informatique distribuée, un espace vraiment complexe. En outre, ils semblent se concentrer sur cela maintenant au lieu des idées "originales". Il me semble qu'il y a un énorme problème de dérapage à moins qu'ils aient pivoté vers l'informatique distribuée parce que les idées originales n'étaient pas assez attrayantes ».
En réponse, un développeur d'Unison a déclaré que ce n'était pas le cas. Un autre commentaire a suggéré que la gestion du code et le calcul distribué ne sont pas si éloignés : « les deux domaines de la gestion du code source et du calcul distribué ne sont pas aussi disjoints dans le contexte d'Unison. Ils découlent du principe sous-jacent d'adresser les fonctions non pas par leur nom, mais par un hash de leur arbre syntaxique normalisé. Il y a un tas d'implications pour le calcul distribué, à savoir que vous pouvez facilement distribuer des parties fines de votre application sur des serveurs et que vous pouvez mettre en cache le résultat de calculs coûteux ».
Un troisième a ajouté : « je pense que le problème de l'informatique distribuée est assez lié une fois que vous avez un code source "adressable par le contenu". Je suis d'accord pour dire que c'est beaucoup de travail, mais j'espère que ça va marcher ». Bien que Chiusano vante les avantages d'Unison, le débat semble se concentrer sur la relation réelle entre l'adressage du code source par le contenu et l'informatique distribuée. En outre, selon ceux qui pensent que cette relation n'existe pas, il n'est pas nécessaire de créer un nouveau langage pour avoir une distribution de code source "adressable par le contenu".
Conclusion
Unison est un pari intéressant qui teste de nouveaux concepts. Toutefois, il est difficile de dire s'il aura un grand avenir ou non. Mais l'idée des développeurs d'Unison est d'aider à repenser la façon dont nous abordons certains aspects du développement logiciel avec les langages de programmation. Pour beaucoup, il ne s'agit pas seulement d'une nouvelle syntaxe, mais plutôt d'un effort plus ambitieux.
Sources : Unison, Référentiel GitHub d'Unison
Et vous ?
Que pensez-vous du langage de programmation Unison ?
Que pensez-vous de l'approche proposée par Unison en matière de programmation distribuée ?
Selon vous, existe-t-il une relation réelle entre l'adressage du code source par le contenu et l'informatique distribuée ?
Voir aussi
La version 5.0 de Celery, le framework de programmation distribuée en Python, est disponible avec une nouvelle implémentation CLI, qui n'est pas complètement rétrocompatible
Jolie, un langage de programmation orienté services, il permet d'agréger directement les API de services dans un serveur Web
YDB, une base de données SQL distribuée et open source, sous licence Apache 2.0, elle fonctionne sur des plateformes x86 64 bits avec un minimum de 8 Go de RAM
Java, Python, Kotlin et Rust connaissent une croissance rapide, mais JavaScript reste le langage de programmation le plus populaire, selon une enquête de SlashData