- Unison ist eine funktionale Programmiersprache, die auf einer Struktur basiert, in der Code-Definitionen nicht über Namen, sondern über ihren Inhalt (Hash) identifiziert werden, und damit die gesamte Art der Codespeicherung, Versionsverwaltung und Bereitstellung neu aufbaut
- Sämtlicher Code wird nicht in Textdateien, sondern in einer Codebase (DB) gespeichert; Namen werden nur als Labels behandelt, wodurch Probleme wie gleichnamige/filebezogene Konflikte und Refactoring-Konflikte strukturell verschwinden
- Über den UCM (Unison Codebase Manager) werden Definitionen hinzugefügt, gelöscht, verschoben, umbenannt, getestet und ausgeführt; dazu kommt ein Ökosystem von Kollaborationstools, das mit LSP, UCM Desktop und Unison Share verbunden ist
- Neben Sprachfunktionen wie einem Effektsystem auf Basis von Abilities, verzögerter Berechnung und strukturellem Pattern Matching wurde das Modell zu einem integrierten Ansatz erweitert, in dem Anwendungslogik und Cloud-Bereitstellung (Cloud/BYOC) innerhalb desselben Programms definiert werden
- Dank der hashbasierten Struktur gehören Vermeidung doppelter Kompilierung, weniger Versionskonflikte und statische Referenzsuche zu den Grundeigenschaften; zusammen mit Share, Cloud, Projects und dem Branch-System entsteht eine konsistente verteilte Entwicklungserfahrung
Überblick über die Sprache Unison
- Definitionen werden in einer content-addressable code-Struktur verwaltet; selbst bei gleichem Namen gelten Inhalte mit unterschiedlichem Inhalt als vollständig verschiedene Definitionen
- Keine Neukompilierung nötig, minimale Konflikte bei der API-Weiterentwicklung, vollständige Referenzstabilität
- Die Codebase wird als SQLite-basierte DB geführt, in der Code, Namen und Dokumentation sämtlich als Daten gespeichert werden
- Strukturen lassen sich mit UCM-Befehlen wie
ls und view erkunden
- Textdateien sind nur eine Schnittstelle zum Bearbeiten; die einzige Quelle der Wahrheit des eigentlichen Quellcodes ist die DB
- Namenskonflikte, Merge-Konflikte in Dateien und die Verwaltung der Repository-Struktur werden dadurch weitgehend zu überholten Konzepten
Sprachfunktionen
- Abilities: Steuerung von Effekten wie IO und Exception über das Typsystem
- Strukturelles Pattern Matching: Zerlegt Typen strukturell, um den Kontrollfluss aufzubauen
- Verzögerte Berechnung (Delayed computations): Drückt nicht-strikte Auswertung explizit aus
- Starke statische Typisierung + umfangreiche Typinferenz + Kind-checking
Entwicklungsumgebung und Toolchain
- UCM (Unison Codebase Manager)
- Erstellen, Löschen, Umbenennen, Testen und Ausführen von Definitionen
- Git-ähnliche Versionsverwaltung wie Projekte, Branches, Klonen und Mergen ist in die Sprache eingebaut
- UCM Desktop
- Erkunden der Codebase-Struktur, klickbasiertes Navigieren zwischen Definitionen, Rendern von Dokumentation
- LSP-Unterstützung
- IDE-Funktionen in den meisten populären Editoren nutzbar
- Unison Share
- Zentraler Code-Hub: Hosting von Projekten, Suche, Reviews, Beiträge (= Pull Requests), typsbasierte Suche
- Da alle Definitionen hashbasiert sind, lassen sich Referenzen immer wie Hyperlinks verfolgen
Bereitstellungsmodell: Unison Cloud & BYOC
- In derselben Sprache werden Anwendungslogik und Infrastrukturdefinition geschrieben und direkt bereitgestellt
- Verteilte Systeme lassen sich ohne YAML, Helm oder komplexe RPC-Konventionen allein als „Code“ aufbauen
- Mit BYOC (Bring Your Own Cloud) kann der Cloud-Stack auch auf eigener Container-Infrastruktur betrieben werden
- Enthält typsicheren Speicher wie OrderedTable, Daemon-Unterstützung und automatische Orchestrierung
Beispiel: Guessing Game
- Einfaches CLI-Beispiel mit Abilities (IO, Exception)
- Sprachmerkmale wie Random, console IO, Pattern Matching und verzögerte Berechnung greifen natürlich ineinander
Ökosystem und Community
- Unterstützung für Beiträge, Reviews und Organisationskonten über Share
- Ecosystem-weite Suche auf Typbasis, Bereitstellung eines MCP-Servers für AI-Agenten
- Arbeiten an einer C FFI werden schrittweise vorangetrieben
- Ausbau von Kollaborationsfunktionen wie Git-style-Diff-Viewer und Branch-Kommentaren
Wichtige Historie (Kurzfassung)
- 2018: Gründung von Unison Computing
- 2019: Erstes Alpha-Release
- 2021: Umstellung der Codebase auf SQLite (100x kleiner)
- 2021: Veröffentlichung von Unison Share
- 2022~2024: LSP, Projects, Kind-checking, Pull Request, Cloud GA
- 2025: Desktop-App, groß angelegte Runtime-Optimierungen, MCP-Server, BYOC-Unterstützung
- Nov 2025: Offizielles Release von Unison 1.0
FAQ
- Warum eine neue Sprache?
- Das hashbasierte Codemodell lässt sich in bestehende Sprachen praktisch nicht als Add-on übertragen
- Da Codespeicherung, Versionsverwaltung, Bereitstellung und Zusammenarbeit alle natürlich aus dieser Idee abgeleitet sind, musste es von Grund auf als neue Sprache entworfen werden
- Praktische Einsatzfälle?
- Die gesamte Unison Cloud wird in Unison selbst geschrieben und betrieben
- Kommerziell nutzbare Workflows für Zusammenarbeit auf Organisations- und Teamebene sowie für die Entwicklung verteilter Anwendungen sind vorhanden
- Sorge vor Vendor Lock-in: Open-Source-Sprache, freie Bereitstellung z. B. mit Docker, plus BYOC-Unterstützung
- Zusammenarbeitsmodell: Unterstützung für Organisationen, Tickets, Code-Reviews, PRs usw.; Konflikte treten nur auf Definitionsebene auf
- Versionsverwaltung: Eigene Funktionen für Projekte, Branches, Push, Pull und Merge ohne Git
- Keine IDE-Beschränkung: Durch den LSP-Server können verschiedene Editoren genutzt werden
- Interoperabilität mit anderen Sprachen: C FFI in Entwicklung
- Zugriff auf die dateilose Codebase: Struktur kann per CLI(UCM)-Befehlen oder Desktop-App erkundet werden
1 Kommentare
Hacker-News-Kommentare
Ich verfolge Unison schon seit sehr langer Zeit. Noch aus der Zeit von Pauls persönlichem Blog, also seit inzwischen mehr als 10 Jahren. Dieses 1.0-Release ist definitiv ein großer Meilenstein, aber ehrlich gesagt bin ich auch ein wenig enttäuscht
Ich interessiere mich sehr für Programmiersprachen und habe das Wachstum von Sprachen wie Rust, Go und Zig ebenfalls miterlebt, aber bei Unison habe ich das Gefühl, dass sich das Ökosystem gemessen an diesem Reifegrad nicht ausreichend verbreitet hat
Ich denke, der Grund dafür ist vor allem ein Geschäftsmodell, bei dem die meisten Funktionen Cloud-abhängig entworfen sind. Es gibt zwar eine BYOC-Option, aber das reicht nicht aus. Irgendetwas daran fühlt sich nicht stimmig an
Das Share-Projekt ist Open Source, und auch GitHub hat faktisch Abhängigkeiten, ist aber trotzdem weiterhin beliebt.
Ich will diese Punkte nicht kleinreden, sondern hoffe eher, dass die Leute es selbst ausprobieren und dabei entdecken, was auch anderen Sprachdesigns helfen könnte
Allerdings setzen die meisten Lernmaterialien die Nutzung von Cloud-Infrastruktur voraus, sodass man in einer Offline-Umgebung schnell nicht weiterkommt.
Vielleicht gibt es einen Unison-typischen Ansatz dafür, aber die Marketing-Ebene verdeckt diesen Weg
Sobald es zahlende Nutzer gibt, entsteht ein Anreiz, die Technik realistisch und praktisch zu halten.
Ohne den kommerziellen Aspekt hätte es sich für mich nur wie noch eine weitere esolang angefühlt. Jetzt überlege ich, es in einem Nebenprojekt auszuprobieren
In der Dokumentation wird Unison Share erwähnt, das ebenfalls auf unison-lang.org gehostet wird.
Es gibt zwar eine BYOC-Option, aber man braucht trotzdem noch ein Konto bei unison.cloud und ein Abonnement. Solche Punkte sollten Marketing und Dokumentation meiner Meinung nach klarer offenlegen
Hallo, ich bin einer der Mitentwickler der Unison-Sprache. Wenn ihr Fragen habt, fragt einfach alles
Unison war eine der ersten Sprachen, die algebraic effects (Abilities) als zentrales Feature in den Vordergrund gestellt haben.
Ich erinnere mich, dass man sich anfangs nicht sicher war, ob dieses Feature gut angenommen würde, und frage mich, ob ihr inzwischen zufrieden damit seid.
Mich würde interessieren, ob sich das Effektsystem gut mit den anderen Teilen der Sprache verbindet, ob euch die Syntax gefällt und ob es spannende Geschichten zur internen Implementierung gibt
Verwandte Dokumentation: Unison Abilities
Wird nur der Hash des Ausdrucks und ein „passed“-Wert gespeichert, oder kann man auch die Hashes aller Werte berechnen?
Falls Letzteres der Fall ist, könnte man damit reproduzierbare Builds wie bei Nix oder Trustix erweitern.
Vermutlich betrifft das aktuelle Caching nur gebundene Ausdrücke, aber es könnte auch als Brücke dienen, um die Laufzeit mit der Außenwelt zu verbinden
Im Moment wirkt es auf mich aber noch wie eine Lösung auf der Suche nach einem Problem.
Mich würde interessieren, an wen sich diese Sprache richtet und ob es außer Unison Cloud noch tatsächliche produktive Einsätze gibt
Zuerst dachte ich, es sei eine BEAM-basierte Sprache, aber sie läuft auf einer eigenen VM.
Mich würde interessieren, welche Unterschiede es im Hinblick auf fault tolerance im Vergleich zu BEAM-Sprachen gibt und für welche Anwendungsfälle Unison besser geeignet ist
Greifen sie auf eine externe Datenbank zu oder sind sie in Unison selbst umgesetzt?
Zusammen mit der Database-Abstraktion ist das eine wirklich spannende Kombination, aber die Konzepte vollständig zu verstehen ist nicht ganz einfach
Ich halte Unison für eine der interessantesten Sprachen überhaupt.
Ich glaube, dass algebraic effects eines der zentralen Konzepte der nächsten Generation sein werden.
Unison hat darüber hinaus noch viele weitere starke Ideen.
Persönlich könnte ich mir die Sprache auch gut für die Entwicklung von Game Mods vorstellen.
Man muss nicht vertrauenswürdigen Code auf dem Client ausführen, und dank des Ability-Systems von Unison könnte man dafür wohl leicht eine Sandbox-Umgebung schaffen.
Außerdem könnte es für die Implementierung eines ECS (Entity Component System) nützlich sein.
Wenn man die Fähigkeiten, die eine Funktion benötigt, ableiten kann, ließe sich die Sicherheit paralleler Ausführung womöglich automatisch gewährleisten
In der Cloud kann man die IO-Ability nicht direkt verwenden, stattdessen sind nur sicher kontrollierte Dinge wie eine Http-Ability erlaubt.
Dadurch wird verhindert, dass Nutzer auf das Dateisystem zugreifen können.
Ich selbst überlege auch, diese Funktion für die Spieleentwicklung zu nutzen.
Andere Nutzer könnten Abilities zudem als native service implementieren und so zum Spiel beitragen.
Weiterführende Links: Unison Cloud, validateSandboxed-Code, ECS-Beispiel
Als ich dieses Projekt zum ersten Mal sah, dachte ich: „Wie wird das wohl in 5 Jahren aussehen?“ Und tatsächlich ist inzwischen genau so viel Zeit vergangen.
Ich freue mich wirklich sehr, jetzt das 1.0-Release zu sehen
Es ist eine großartige Leistung, eine so radikale Sprache so weit zu bringen, dass sie auch in realen Industrieumgebungen einsetzbar ist. Glückwunsch
Ich glaube, dass Systeme wie Unison die Zukunft des Computings sind.
Aber ich weiß nicht, wann diese Zukunft kommt.
Das Schöne an solchen Systemen ist, dass Infrastruktur-, Daten- und Service-Schicht in einem einzigen integrierten System zusammenkommen.
Vielleicht ist das auch eine bessere Grundlage für AI Coding Agents.
Allerdings denke ich, dass nachhaltige unabhängige Entwicklung besser dazu passt als ein VC-Modell.
Es ist wirklich beeindruckend, dass dieses Team ein so langfristiges Projekt weiterführt
Ich erinnere mich noch an den Tag, an dem Rúnar sagte, dass er Unison starten würde.
Ich hielt es damals für ein Projekt, das ein völlig neues Paradigma eröffnet, und jetzt das 1.0-Release zu sehen, macht mich wirklich stolz.
Ich hoffe, dass Unison eines Tages zu meiner primären Sprache wird
Ich wünschte, die Unison-Website hätte Benchmarks.
Man muss die Performance-Eigenschaften kennen, um einschätzen zu können, wofür sie geeignet ist.
Schon einfache Zahlen wie ein Vergleich der Request-Verarbeitungsgeschwindigkeit mit Django, Express.js und ASP.NET wären hilfreich.
Die Ideen sind interessant, aber ich hoffe auch auf Runtime-Ziele jenseits des Webs.
Persönlich probiere ich neue Sprachen leichter bei CLI-Tools aus als in großen Webprojekten
Ich habe mich auf diesen Unison-Review-Artikel von 2023 bezogen, und er war ziemlich hilfreich
Die Ideen sind interessant, aber Unison ist eine All-in-one-Struktur, bei der man Sprache + Source Management + Hosting auf einmal übernehmen muss.
Wenn einem auch nur ein Teil dieses Stacks nicht zusagt, ist es schwer, das Ganze zu verwenden.
Deshalb glaube ich, dass sich solche Ideen in direkter Form nur schwer breit durchsetzen werden
Die Tooling-Qualität der Sprache selbst ist sehr hoch, und eine Integration in bestehende Systeme ist ebenfalls möglich.
Unison Cloud ist zum Beispiel größtenteils in Unison geschrieben, verwendet teilweise aber auch Haskell.
Verwandte Diskussionen: HN-Thread 1, HN-Thread 2
Ich denke, es liegt großer Wert darin, mehrere Technologien organisch zu entwerfen, sodass sie gut zusammenarbeiten