Sky: Elm-Syntax, die nach Go übersetzt und eine statische Binärdatei ausgibt

Was Sky aus Elm-Syntax macht und wohin der Code geht

Sky ist eine funktionale Sprache für vollständige Anwendungen, die nach Go übersetzt wird. Das Repository anzellai/sky weist Go als Hauptsprache aus, steht unter Apache-2.0 und wurde zuletzt am 25. August 2026 bewegt. Die Statuszeile des README spricht von v0.23.x, während als jüngstes getaggtes Release v0.22.1 vom selben Tag vorliegt. Wer die Daten nebeneinanderlegt, sieht einen dichten Takt: v0.21.1 am 20. August, v0.22.0 am 24. August, v0.22.1 am 25. August 2026.

Geschrieben wird in Elm-ähnlicher Syntax mit expliziten Typen und erschöpfendem Pattern Matching. Das kleinste Programm besteht aus module Main exposing (main), einem Import von Std.Log exposing (println) und der Zeile main = println "Hello from Sky!". Zum Laufen bringt es sky init hello && cd hello && sky run src/Main.sky.

Das Ergebnis ist kein Framework, sondern eine statische Go-Binärdatei. Ausliefern lässt sie sich laut README per scp, per Docker oder als Kommandozeilenwerkzeug über brew install. Laufzeit, Standardbibliothek und Sky Console stecken im sky-Binary selbst, zusätzliche Installationen auf dem Zielsystem sind für den Betrieb nicht vorgesehen.

Task Error a, Result Error a und sky check mit go build

Das Leitversprechen heißt: Wenn es kompiliert, funktioniert es. Konkret bedeutet das nach Angabe des README, dass jeder Seiteneffekt Task Error a zurückgibt und jeder fehlschlagbare Wert Result Error a. Es soll kein null zur Laufzeit geben, keine unbehandelte Ausnahme und keine stillschweigende Umwandlung zwischen Zahlentypen.

Wie belastbar die Zusage ist, hängt an der Werkzeugkette. Der Befehl sky check ruft go build auf dem erzeugten Go-Code auf. Formfehler, die der eigene Übersetzer nicht erkennt, landen damit trotzdem in der Typprüfung und nicht erst im Betrieb. Das ist ein praktischer Trick: Sky leiht sich den Go-Compiler als zweite Prüfinstanz, statt einer Codegenerierung ohne Kontrolle zu vertrauen.

Für ein Team dürfte der Alltagsgewinn woanders liegen, nämlich darin, dass Fehlerfälle im Typsystem sichtbar sind statt in einem Stacktrace. Das README verweist außerdem auf eine mitgelieferte CLAUDE.md im Wurzelverzeichnis und auf eine vom Generator sky init angelegte Fassung, die einem KI-Assistenten den nötigen Kontext geben sollen. Dass daraus im ersten Anlauf übersetzbarer Code entsteht, ist eine Selbstauskunft des Projekts und durch das Material nicht belegt.

Sky.Live, Sky.Spa, Sky.Tui: ein init/update/view, mehrere Ziele

Alle Bauformen teilen dieselbe TEA-artige Struktur aus init, update, view und subscriptions. Der Unterschied liegt darin, wo die Schleife läuft und wie ausgeliefert wird.

Sky.Live rendert serverseitig. Laut README entfällt ein Client-Build, der Zustand gehört dem Server, Aktualisierungen kommen über eine SSE-Verbindung pro Sitzung. Der Einstieg heißt Live.app (Live.config {…}), als heutiges Ziel nennt das README den Browser. Sky.Spa übersetzt dieselbe Quelle nach wasm für den Client, Einstieg über Spa.app (Spa.config {…}), gedacht für Web, Desktop, iOS und Android, wenn Übergänge lokal und ohne Roundtrip ablaufen sollen und das Backend eine zustandslose API ist. Diese Form ist jung: Sie trägt die Release-Nummer v0.22.0 vom 24. August 2026, das Release trägt den Titel «Sky.Spa: one language, every platform».

Dazu kommen Sky.Http.Server mit Server.listen 8000 [...] für JSON-Schnittstellen und Sky.Tui für Anwendungen im Terminal. Dieselbe Std.Ui-Ansicht soll wahlweise ins DOM, in ANSI-Zellen oder in ein natives Webview-Fenster zeichnen. Ob eine Ansicht in jeder Bauform identisch aussieht, geht aus dem Material nicht hervor; die verfügbare Fassung des README bricht an dieser Tabelle ab.

sky add und die Stripe-Zahl: Go-Pakete als typisierte Bindings

Der Zugang zum Go-Ökosystem läuft über sky add github.com/some/package. Der Übersetzer untersucht das Paket und erzeugt daraus nach Angabe des README strenge, typisierte Sky-Bindings, ohne dass handgeschriebener FFI-Kleber nötig wäre.

Als Größenordnung führt das Projekt das Stripe-SDK an: rund 76000 FFI-Symbole, die übersetzt und durch Tree-Shaking zu einer main.go mit etwa 4000 Zeilen werden. Diese Zahl ist selbst berichtet und steht nur in der README; im Material fehlt jeder unabhängige Nachweis, ebenso eine Angabe zur benötigten Build-Dauer. Zum Beurteilen taugt sie deshalb allein als Hinweis, dass der Pfad überhaupt begehbar ist, nicht als Leistungsaussage.

Neben dem FFI listet das README eine breite Standardbibliothek: Std.Db, Std.Auth, Std.Ui, Std.Cache und Std.Email werden namentlich genannt, dazu HTTP-Client und Server, WebSocket, JSON, JWT, CSV, Verschlüsselung und Beobachtbarkeit. Dokumentiert wird das über sky doc --serve. Als Neuerung von v0.23 nennt die Statuszeile Std.App, einen Builder mit einem --target-Schalter für alle Anwendungsformen, sowie Sky.Core.Secret als typisierten Geheimniswert, der sich in Ausgaben selbst unkenntlich macht.

Warum der Sky-Übersetzer in Rust unter rust/ neu geschrieben wurde

Bis v0.17 trug ein in Haskell geschriebener Übersetzer das Projekt. Die README begründet den Wechsel mit drei strukturellen Punkten: ein monolithischer Senkungsschritt über mehrere tausend Zeilen, veränderlicher Compiler-Zustand über IORef, der der von Sky versprochenen Reinheit widersprach, und ein Hindley-Milner-Löser, der nur mit festen Speicherbudgets begrenzt blieb.

Der Neubau liegt als Cargo-Workspace unter rust/ und ist in kleine Crates mit je einer Verantwortung zerlegt: Lexer und Parser, Namensauflösung, HM-Inferenz, typgesteuerte Senkung, Go-Codegenerierung, FFI, Formatierer und LSP. Ein query-DAG als Kern soll inkrementelle Neubauten und modulübergreifende Analyse von sich aus stabil machen. Für gerade Rust nennt das README kürzere Übersetzungszeiten des Korpus, ein niedrigeres und planbareres Speicherprofil sowie algebraische Enums mit erzwungener Vollständigkeit und ohne null.

Bemerkenswert ist die Absicherung des Wechsels. Der alte Haskell-Übersetzer bleibt unter legacy-haskell-compiler/ und dient laut README als Differenz-Orakel, bis v1 getaggt ist. Neu hinzukommende Sprachmittel müssen also dieselbe Ausgabe liefern wie die alte Implementierung. Das sagt nichts über die Korrektheit beider Fassungen, verhindert aber stille Rückschritte beim Umschreiben. Copyright und Lizenzwechsel sind in NOTICE.md festgehalten: Bis einschließlich v0.10.0 lief das Projekt unter MIT, ab v0.10.1 unter Apache-2.0, Copyright 2025 bis 2026 Anzel Lai; Teile des Typrückschlusskerns stammen aus elm/compiler unter BSD-3-Clause.

Installationswege: install.sh, cargo build und Go 1.21+

Für macOS und Linux nennt das README einen Einzeiler: curl -fsSL https://raw.githubusercontent.com/anzellai/sky/main/install.sh | sh. Ein Skript aus dem Netz unmittelbar in die eigene Shell zu leiten, ist eine Vertrauensentscheidung; wer sie vermeiden will, baut aus dem Quellcode.

Dann ist eine Rust-Toolchain erforderlich. Der Weg führt über git clone des Repositories, cd sky/rust und cargo build --release -p sky, alternativ direkt nach ~/.local/bin mit cargo install --path rust/crates/sky --root ~/.local --locked. Für Anwendende reicht danach sky im PATH zusammen mit Go 1.21+ für die Codegenerierung. Eine Windows-Installation beschreibt das Material nicht, auch keine Mindestversion von Rust; in der Dokumentation nicht angegeben.

Für den Betrieb nennen die Projektangaben sky build src/Main.sky, erzeugt wird eine ausführbare Datei unter ./sky-out/app. Laufende Anwendungen hängen Beobachtbarkeitsendpunkte unter /_sky ein, namentlich console, metrics, healthz, readyz und buildinfo; metrics ist als Prometheus-Ziel mit Zählern und Histogrammen beschrieben. Der Schutz der Konsole in Produktion läuft über SKY_CONSOLE_AUTH. Zwischen Entwicklungs- und Produktionsmodus schaltet ENV beziehungsweise SKY_ENV: leer oder auf dev, development oder local bleibt die Entwicklungskonsole offen, jeder andere Wert sperrt sie samt Banner und metrics-Endpunkt. Telemetrie geht wahlweise über OTEL_EXPORTER_OTLP_ENDPOINT an einen OpenTelemetry-Collector oder über HubExporter an einen Hub, den sky console serve bereitstellt.

Sky gegen direktes Go, und was vor v1 offen bleibt

Die nächstliegende Alternative ist, gleich in Go zu schreiben. Der Unterschied sitzt in den Garantien und in den Kosten. Sky erzwingt die Elm-artige Typdisziplin und führt Fehlerfälle über Result Error a durch den Typrüfer, verlangt dafür eine zweite Toolchain und einen Übersetzer im v0-Stadium, dessen Interna sich laut README zwischen Nebenversionen ändern dürfen. Direktes Go bietet diese Garantien nicht, benötigt aber nur eine Toolchain und keinen Generierungsschritt für fremde Pakete.

An der Sprachherkunft lässt Sky keinen Zweifel: Syntax und Architektur sind von Elm abgeleitet. Was Elm heute leistet, bewertet das Material nicht, deshalb bleibt ein Vergleich an dieser Stelle offen. Fest steht nur, wohin Sky selbst will: eine Quelle, die über Std.Ui mehrere Ausgabeziele bedient und am Ende als statische Go-Binärdatei herausfällt.

Offen bleibt einiges. Die Statuszeile sichert stabile öffentliche Schnittstellen nur für die v1.0-Linie zu. Sky.Spa war zum Zeitpunkt des jüngsten Releases wenige Tage alt. Die verfügbare README-Fassung ist hinter der Tabelle der Anwendungsformen abgeschnitten, sodass sich die Kriterien für Sky.Tui und Sky.Webview daraus nicht rekonstruieren lassen. Wer die Sprache ernsthaft erwägt, sollte deshalb die Dokumentation unter sky-lang.org und den Tour unter anzellai.github.io/sky/ als Primärquelle nutzen und den Probebuild auf eigenen Paketen vor die Architekturentscheidung setzen.

Redaktionelles Fazit

Sky passt zu Teams, die Go als Laufzeit wollen, Fehlerfälle aber lieber im Typsystem als in Laufzeitprüfungen klären, und die mehrere Oberflächen aus einer Quelle bedienen müssen. Es passt nicht für Vorhaben, die eine stabile interne Schnittstelle brauchen: Die README sagt ausdrücklich, dass sich Interna zwischen Nebenversionen ändern können, und mit v0.21.1, v0.22.0 und v0.22.1 innerhalb von sechs Tagen ist dieser Satz keine Formalie. Vor der Entscheidung sollte ein Probebuild mit sky check und anschließend sky build src/Main.sky über den eigenen Go-Paketen stehen, weil daran sichtbar wird, ob die von sky add erzeugten Bindings die benötigten Schnittstellen wirklich abdecken.

Offizielle Quellen

1. Official README
2. Project repository
3. Release notes