Sky: An Elm-Inspired Language That Compiles to Typed Go

What Sky Solves and Who It Is For

Sky targets developers who want the guarantees of a statically typed functional language without leaving the Go ecosystem. The README claims 'if it compiles, it works': every side effect returns a Task Error a, every fallible value returns a Result Error a, and sky check runs go build on the emitted Go so shape mismatches surface at type-check time. There is no runtime null, no uncaught exception, and no silent numeric coercion. This is aimed at teams building fullstack applications where correctness matters more than raw speed, and who want to ship a single static binary. It is also pitched as AI-friendly, because explicit annotations and exhaustive pattern matching make generated code more likely to compile. If you are a Go developer who misses Elm's architecture, Sky offers a way to keep that model while staying in Go's deployment world.

The Architecture: From Elm Syntax to Typed Go

Sky compiles Elm-style source code to typed Go. The compiler is written in Rust, organized as a cargo workspace of small crates: lexer/parser, name resolution, HM inference, type-directed lowering, Go codegen, FFI, formatter, and LSP. The README explains that the Haskell compiler was retired because of structural problems: a monolithic lowering pass, mutable IORef state, and an HM solver that needed hard memory budgets. The Rust rewrite uses a query-DAG core for incremental rebuilds and cross-module analysis. The typed-Go output and the 'if it compiles, it works' contract carry over unchanged. The Haskell compiler remains in the repository as a byte-for-byte differential oracle until v1 is tagged. This design means that the compiler itself enforces the same discipline it compiles: algebraic enums, exhaustive matching, and no null. The architecture is a real change from the Haskell version, and it is worth noting that the compiler is now written in a language that is not Go, which may matter for teams that want to contribute.

Getting Started: Install, Init, and Run

Installation is a single-binary script for macOS and Linux: curl -fsSL https://raw.githubusercontent.com/anzellai/sky/main/install.sh | sh. Alternatively, you can build from source with a Rust toolchain: git clone, cd sky/rust, and cargo build --release -p sky. The sky binary embeds the runtime, stdlib, and Sky Console. End users need only sky on PATH and Go 1.21+ for codegen. To start a project, run sky init hello, then sky run src/Main.sky. The README shows a minimal Hello World and a counter web app. The counter uses Std.Live.app, Std.Ui, and a standard Elm architecture: init, update, view. You can add Std.Tui.app for a terminal UI or Std.Webview.app for a native desktop window. The sky doc --serve command documents the stdlib.

Targets: Sky.Live, Sky.Spa, Sky.Tui, and More

The same init/update/view/subscriptions source compiles to different targets. Sky.Live is a server-driven web app with server-owned state and real-time updates over SSE. Sky.Spa compiles to wasm for client-side rendering, targeting web, desktop, iOS, and Android. Sky.Tui renders the same Std.Ui view to ANSI cells in a terminal. Sky.Webview gives a native desktop window. There is also Sky.Http.Server for JSON/REST APIs without a UI. The choice depends on where the loop should run: Sky.Live for zero client build and instant first paint, Sky.Spa for instant local UI transitions with a stateless backend. The README's table is clear about when to use each. This is a genuinely flexible architecture, but it means you need to understand the trade-offs of server-driven vs. client-side state from the start.

The Go Ecosystem and FFI

Sky lets you import any Go package with sky add github.com/some/package. The compiler introspects the Go package and generates strict, typed Sky bindings, with no hand-written FFI glue. The README gives an example: the Stripe SDK, which has roughly 76k FFI symbols, compiles and tree-shakes to a 4k-line main.go. This is a strong claim, but it is from the project's own documentation. The mechanism is type-directed lowering: the compiler reads Go's type information and produces Sky types, which then flow through the normal type checker. This is a different approach from languages that require manual binding definitions. The practical effect is that you can use Go's ecosystem directly, but the quality of the bindings depends on how well the introspector handles complex Go types. It is a feature that is hard to verify without running it, and you should test it against your own dependencies before relying on it.

Limitations and When It Is the Wrong Tool

Sky is young. The project is at v0.23.x, and while the README says public APIs are stable for the v1.0 line, internals can change between minor versions. The compiler is written in Rust, which means contributing to the compiler requires Rust knowledge, not Go. The toolchain requires Go 1.21+ for codegen, so you cannot use Sky in an environment that does not have Go available. The server-driven UI model (Sky.Live) depends on SSE, which may not fit every deployment. The AI-friendly claim is a design goal, not a proven outcome. If you need a language with a large community, mature IDE support, or a stable ecosystem, Sky is not there yet. Also, the README mentions that the Haskell compiler is still used as a differential oracle, which suggests that the Rust compiler is not yet fully trusted for all cases. If you are building a critical system, you should wait for v1 or at least run extensive tests.

Alternatives and How They Differ

The most direct alternative is Elm itself. Elm compiles to JavaScript and has a mature ecosystem, but it does not compile to Go and does not offer server-driven UI in the same way. If you want a functional language on the JVM, Frege is a Haskell-like language that compiles to Java, but it does not have the same Go integration. For server-driven UI, Phoenix LiveView is a mature framework, but it uses Elixir and a different programming model. The key difference is that Sky compiles to typed Go, which means you get Go's static binaries and the ability to import any Go package. Elm and Frege do not offer that. If you are already invested in Go, Sky is the only language that gives you Elm-style syntax with Go output. If you are not invested in Go, Elm or another functional language might be a better fit.

Maintenance and Upgrade Costs

The project is actively maintained, with the last push on 2026-08-25 and releases v0.22.1, v0.22.0, and v0.21.1 within a week. The v0.22.0 release notes mention Sky.Spa, and v0.23.x adds Std.App and Sky.Core.Secret. The README states that minor versions ship features additively, so upgrades should be low-risk, but internals can change. You should read the release notes before upgrading. The license is Apache-2.0, which is permissive and allows commercial use, but you should check the license of any Go packages you import. The compiler is a Rust workspace, so building from source requires a Rust toolchain, but the install script provides a binary. The maintenance cost is mainly in keeping up with minor version changes and testing your FFI bindings after upgrades. The differential oracle suggests that the Rust compiler is still being validated, so expect occasional changes in generated Go code.

Editorial conclusion

Adopt Sky if you want an Elm-style, statically typed language that compiles to a single Go binary, and if you accept a young ecosystem and a compiler written in Rust. Avoid it if you need mature IDE support, a large community, or if you cannot rely on Go 1.21+ for codegen. Before committing, verify that the v1.0 API stability promise holds for your use case, and test the FFI binding generation against the Go packages you depend on. The differential oracle against the Haskell compiler is still active until v1, so expect internal changes. If you need a more mature functional language on the JVM, look at Frege; for a battle-tested server-driven UI framework, consider Phoenix LiveView.

Official sources

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