- Unison est un langage de programmation fonctionnel fondé sur une structure qui identifie les définitions de code par leur contenu (hash) plutôt que par leur nom), repensant ainsi entièrement les modes de stockage, de gestion de versions et de déploiement du code
- Tout le code est stocké non pas dans des fichiers texte mais dans une codebase (DB), où les noms ne sont traités que comme de simples étiquettes, ce qui fait disparaître structurellement des problèmes comme les conflits de noms/fichiers identiques et les conflits de refactorisation
- Avec l’UCM (Unison Codebase Manager), on peut ajouter, supprimer, déplacer, renommer, tester et exécuter des définitions, avec un écosystème d’outils collaboratifs relié à LSP, UCM Desktop et Unison Share
- Au-delà des fonctionnalités du langage comme le système d’effets basé sur les Abilities, les calculs différés et le pattern matching structurel, le modèle s’étend à une approche intégrée où la logique applicative et le déploiement cloud (Cloud/BYOC) sont définis ensemble dans un même programme
- Grâce à la structure fondée sur les hash, des propriétés comme l’élimination des compilations redondantes, la réduction des conflits de version et l’exploration statique des références deviennent natives, offrant une expérience cohérente de développement distribué incluant Share, Cloud, Projects et le système de Branch
Aperçu du langage Unison
- Les définitions sont gérées selon une structure de code adressé par le contenu (content-addressable code), de sorte que même si le nom est identique, un contenu différent est traité comme une définition entièrement distincte
- Pas de recompilation inutile, conflits d’évolution d’API minimisés, stabilité complète des références
- La codebase est maintenue dans une DB basée sur SQLite, où code, noms et documentation sont tous stockés comme des données
- Exploration de la structure avec les commandes UCM comme
ls et view
- Les fichiers texte ne sont qu’une interface d’édition ; l’unique source de vérité réelle est la DB
- Les conflits de noms, conflits de fusion de fichiers et la gestion de structure de repo deviennent des concepts largement dépassés
Fonctionnalités du langage
- Abilities : mécanisme permettant de contrôler via le système de types des effets comme IO ou Exception
- Pattern matching structurel : composition du flux de contrôle par décomposition structurelle des types
- Calculs différés (Delayed computations) : expression explicite de l’évaluation non stricte
- Typage statique fort + riche inférence de types + vérification des kinds
Environnement de développement et toolchain
- UCM (Unison Codebase Manager)
- Création, suppression, renommage, test et exécution de définitions
- Gestion de versions de type Git intégrée au langage avec projets, branches, clones et merges
- UCM Desktop
- Exploration de la structure de la codebase, navigation par clic entre définitions, rendu de documentation
- Support LSP
- Fonctionnalités d’IDE utilisables dans la plupart des éditeurs populaires
- Unison Share
- Hub central de code : hébergement de projets, recherche, review, contribution (= Pull Request), recherche basée sur les types
- Comme toutes les définitions reposent sur des hash, les références sont toujours navigables comme des hyperliens
Modèle de déploiement : Unison Cloud & BYOC
- Avec le même langage, on écrit la logique applicative + la définition de l’infrastructure, puis on déploie le tout directement
- Construction de systèmes distribués uniquement avec du « code », sans YAML, Helm ni protocoles RPC complexes
- Avec BYOC (Bring Your Own Cloud), il est aussi possible d’exécuter la stack Cloud sur sa propre infrastructure de conteneurs
- Inclut des éléments comme des stores typés et sûrs tels que OrderedTable, le support des daemons et l’orchestration automatique
Exemple : Guessing Game
- Exemple CLI simple utilisant les Abilities (IO, Exception)
- Combinaison naturelle d’éléments du langage comme Random, les entrées/sorties console, le pattern matching et les calculs différés
Écosystème et communauté
- Support des contributions, reviews et comptes d’organisation via Share
- Recherche dans tout l’écosystème basée sur les types, et serveur MCP pour les agents IA
- Travaux en cours pour un C FFI
- Extension des fonctions de productivité collaborative, comme un visualiseur de diff de style Git et des annotations de branche
Historique principal (résumé)
- 2018 : fondation de Unison Computing
- 2019 : première release alpha
- 2021 : migration de la codebase vers SQLite (taille réduite de 100x)
- 2021 : lancement public de Unison Share
- 2022~2024 : LSP, Projects, kind-checking, Pull Request, Cloud GA
- 2025 : application Desktop, optimisations runtime à grande échelle, serveur MCP, support BYOC
- Nov. 2025 : sortie officielle de Unison 1.0
FAQ
- Pourquoi un nouveau langage ?
- Le modèle de code fondé sur les hash est quasiment impossible à porter dans les langages existants sous forme d’addon
- Comme le stockage du code, la gestion de versions, le déploiement et la collaboration découlent tous naturellement de cette idée, il fallait concevoir un nouveau langage dès le départ
- Cas d’usage réels ?
- L’intégralité de Unison Cloud est elle-même écrite en Unison et déjà exploitée en production
- Un workflow de niveau commercial est en place pour la collaboration à l’échelle d’une organisation ou d’une équipe et pour le développement d’applications distribuées
- Préoccupation de dépendance fournisseur : langage open source, déployable librement avec Docker, avec support BYOC
- Mode de collaboration : prise en charge des organisations, tickets, code reviews, PR, avec des conflits limités au niveau des définitions
- Gestion de versions : fournit ses propres fonctions de projets, branches, push, pull et merge sans Git
- Aucune contrainte d’IDE : serveur LSP disponible pour utiliser divers éditeurs
- Interopérabilité avec d’autres langages : C FFI en cours de développement
- Accès à une codebase sans fichiers : exploration de la structure possible via les commandes CLI (UCM) ou l’application Desktop
1 commentaires
Avis Hacker News
Je suis Unison depuis très longtemps. Depuis l’époque du blog personnel de Paul, donc ça fait déjà plus de 10 ans. Cette sortie en 1.0 est vraiment une étape majeure, mais honnêtement je suis un peu déçu
J’aime vraiment les langages de programmation, donc j’ai aussi suivi la croissance de Rust, Go et Zig, et j’ai l’impression qu’Unison manque de diffusion dans l’écosystème par rapport à son niveau d’aboutissement
Je pense que cela vient surtout d’un modèle économique où la plupart des fonctionnalités sont conçues de manière dépendante du cloud. Il existe bien une option BYOC, mais ce n’est pas suffisant. L’ensemble dégage une impression un peu étrange
Le projet Share est open source, et GitHub a lui aussi une dépendance de fait, tout en restant populaire.
Ce n’est pas pour nier ces points, mais j’aimerais que les gens l’essaient eux-mêmes et voient ce que cela peut apporter à la conception d’autres langages
Mais la plupart des ressources d’apprentissage partent du principe qu’on utilise une infrastructure cloud, donc en environnement hors ligne on se retrouve vite bloqué.
Il existe peut-être une approche propre à Unison, mais la couche marketing masque cette possibilité
S’il y a des utilisateurs payants, il y a aussi une motivation pour garder la technologie réaliste et pratique.
Sans cet aspect commercial, cela aurait simplement ressemblé à un autre esolang. Je pense maintenant l’essayer sur un projet perso
La documentation mentionne Unison Share, mais c’est aussi hébergé sur unison-lang.org.
Il existe une option BYOC, mais il faut toujours un compte et un abonnement unison.cloud. J’aimerais que le marketing et la documentation soient plus clairs sur ce point
Bonjour, je suis l’un des co-créateurs du langage Unison. N’hésitez pas à me poser toutes vos questions
Unison est l’un des premiers langages à avoir mis en avant les algebraic effects (Abilities) comme fonctionnalité majeure.
Si je me souviens bien, au début vous n’étiez pas certains que cette fonctionnalité serait bien accueillie, et je serais curieux de savoir si vous en êtes satisfaits aujourd’hui.
J’aimerais aussi savoir si le système d’effets s’intègre bien au reste du langage, si la syntaxe vous plaît, et entendre quelques anecdotes intéressantes sur l’implémentation interne
Documentation associée : Unison Abilities
Est-ce que vous stockez seulement le hash de l’expression et la valeur « passed », ou bien est-il aussi possible de calculer le hash de toutes les valeurs ?
Si c’est le second cas, cela pourrait permettre d’étendre les builds reproductibles à la manière de Nix ou Trustix.
J’imagine qu’aujourd’hui le cache ne traite que les expressions liées, mais il pourrait aussi servir de passerelle vers le monde extérieur à l’exécution
Cela dit, pour l’instant, j’ai l’impression d’une solution à la recherche d’un problème.
Je me demande à qui s’adresse ce langage, et s’il existe des usages réels en production en dehors d’Unison Cloud
Au début, je pensais que c’était un langage basé sur BEAM, mais il fonctionne sur sa propre VM.
Je me demande quelles sont les différences avec les langages BEAM en matière de tolérance aux pannes, et dans quels cas d’usage Unison serait mieux adapté
Est-ce qu’elles appellent une base de données externe, ou bien sont-elles implémentées dans Unison lui-même ?
En combinaison avec l’abstraction Database, c’est un ensemble vraiment intéressant, mais pas facile à comprendre complètement
Je considère Unison comme l’un des langages les plus intéressants qui soient.
Je crois que les algebraic effects vont devenir un concept central de la prochaine génération.
Unison a aussi beaucoup d’autres idées brillantes.
Personnellement, je pense qu’il pourrait aussi convenir au développement de mods de jeux.
Il faut exécuter du code non fiable côté client, et grâce au système d’abilities d’Unison, il devrait être facile de créer un environnement sandbox.
Cela pourrait aussi être utile pour implémenter un ECS (Entity Component System).
Si l’on peut inférer les capacités dont une fonction a besoin, on pourrait automatiquement garantir la sûreté de l’exécution en parallèle
Dans Cloud, on ne peut pas utiliser directement l’ability IO, et seules des capacités sûres et contrôlées comme l’ability Http sont autorisées.
Cela empêche ainsi les utilisateurs d’accéder au système de fichiers.
J’envisage moi aussi d’exploiter cette fonctionnalité pour le développement de jeux.
D’autres utilisateurs pourraient aussi contribuer au jeu en implémentant des abilities sous forme de native service.
Liens de référence : Unison Cloud, code validateSandboxed, exemple ECS
Quand j’ai vu ce projet pour la première fois, je me suis dit : « à quoi cela ressemblera dans 5 ans ? », et ce temps s’est réellement écoulé.
Je suis vraiment heureux de voir maintenant la sortie en 1.0
C’est une réalisation remarquable d’avoir rendu un langage aussi radical utilisable dans un environnement industriel réel. Félicitations
Je pense qu’un système comme Unison représente l’avenir de l’informatique.
Mais je ne sais pas quand cet avenir arrivera.
La beauté de ce genre de système, c’est que l’infrastructure, les données et la couche de services y sont réunies dans un système unifié.
Cela pourrait peut-être aussi constituer une meilleure base pour des agents de codage IA.
Cela dit, je pense qu’un développement indépendant et durable conviendrait mieux qu’un modèle VC.
C’est vraiment admirable qu’une équipe poursuive un projet aussi long terme
Je me souviens du jour où Rúnar a dit qu’il allait lancer Unison.
J’y ai vu un projet ouvrant un paradigme entièrement nouveau, et maintenant que je vois cette sortie en 1.0, j’en suis vraiment fier.
J’espère qu’Unison deviendra un jour mon langage principal
J’aimerais qu’il y ait des benchmarks sur le site web d’Unison.
Il faut connaître ses caractéristiques de performance pour savoir à quels usages il convient.
Même quelques chiffres simples, comme une comparaison de débit de traitement des requêtes avec Django, Express.js et ASP.NET, seraient utiles.
Les idées sont intéressantes, mais j’espère aussi voir apparaître des cibles d’exécution autres que le web.
Personnellement, il m’est plus facile d’essayer un nouveau langage sur des outils comme des CLI que sur de gros projets web
Je me suis référé à cette critique d’Unison publiée en 2023, et je l’ai trouvée assez utile
Les idées sont intéressantes, mais Unison est une structure tout-en-un où il faut adopter à la fois le langage + la gestion des sources + l’hébergement.
Si un seul élément de la pile ne convient pas, il devient difficile d’utiliser l’ensemble.
C’est pourquoi je pense que ces idées auront du mal à se diffuser largement de manière directe
La qualité de l’outillage du langage lui-même est très élevée, et il peut aussi s’intégrer à des systèmes existants.
Par exemple, Unison Cloud est majoritairement écrit en Unison, mais certaines parties utilisent Haskell.
Discussions associées : fil HN 1, fil HN 2
Je pense qu’il y a une grande valeur à concevoir plusieurs technologies de manière organique pour qu’elles fonctionnent bien ensemble