-
Notifications
You must be signed in to change notification settings - Fork 25
Language support
Hydra targets many programming languages, supported to varying degrees. "Hydra can generate code in language X" is a much weaker statement than "language X is a production-supported Hydra host," and the gap between them has several distinct stages. This page describes the stages and places each language, so a user can tell how much weight a language can bear.
This is a current-status page: support levels evolve release to release, and the in-progress items below link to the issues tracking them. It is a production-readiness lens over the factual per-head status in the README Implementations table; where the two differ in detail, the README's status column is authoritative and this page should be updated to match. For what is published where, see Releases; for release policy, see Release-policy.
Support advances along a few related-but-distinct axes. A language is more supported the further it gets along each.
- Type-level coder. Translates Hydra types into the target language. This is where a new language starts: you can express Hydra's schemas, but not yet its programs.
- Two-level coder. Translates both types and terms, conformance-preserving — the generated terms behave identically to the source. This is the jump from "express the schema" to "express and run the programs," and it is what the hydra-kernel test suite verifies.
A head is the realization of the Hydra kernel in a host language: generated code plus the hand-written runtime, primitives, and bootstrapping infrastructure that make Hydra usable on that host. Heads are graded by how far they take the hydra-kernel test suite (the common test suite that ensures every program behaves identically across languages):
- No test runner — the coder emits code, but the head cannot yet run the kernel test suite.
- Test runner, partial pass — the head runs the suite, but not all tests pass.
- Complete — all hydra-kernel tests pass. (A small set of cases is currently ignored pending #513; "complete" means all non-ignored tests pass.)
Complete heads are expected to bootstrap each other: starting from the JSON kernel, generate the hydra-kernel main and test sources into another language and call that language's test runner to demonstrate the tests pass there too. This is pairwise — a head may bootstrap some languages and not others.
- The default bootstrapping run gates
main: Haskell, Java, and Python must all mutually bootstrap (each generating and test-running the others) before any change lands onmain. - Not all heads meet this bar for all other heads yet. #409 (everything-to-everything bootstrapping) is closing the remaining gaps.
Now that Hydra supports effects, heads divide into effectful (the host can perform I/O and other effects, so the full kernel — including effectful tests — runs) and effect-less (the host cannot, so the head is complete only for the pure subset). An effect-less head is complete for what it can express; it is not an unfinished effectful head. A host without I/O (e.g. Coq, were it pursued) would be the first effect-less case — complete for the pure subset by design, not by immaturity. No effect-less head is in use today.
The fullest expression of "translingual": can Hydra source modules be authored in the language (using a host-native DSL), not merely generated into it? An authoring language is both a place you write Hydra and a target everything else can be generated from.
This is the frontier, and it is orthogonal to the head tier — a language can have a complete, production-supported head yet not (yet) support authoring. Demonstrated today in four languages:
- Haskell — the original authoring language; most kernel and package modules have Haskell-based sources.
-
Java (
hydra-java), Python (hydra-python), and Scala (hydra-scala) — their coder DSL sources are authored host-natively (in Java, Python, and Scala), and are the sole source of truth for the generated output — demonstrating native authoring beyond Haskell.
No other language supports authoring translingual sources yet, though that is the plan for all of them.
The two extra columns capture distinctions worth stating plainly: "Authoring" is host-native DSL support for writing Hydra sources (the frontier — planned everywhere, demonstrated in H/J/P/S only); "Published" is whether versioned release artifacts actually ship for that language today (published / ready, not yet / not yet).
Every axis is satisfied: a complete head, all non-ignored hydra-kernel tests pass, the language is in
the main bootstrapping gate, published, and production-tested. These are the languages to build on
in production.
| Language | Head | Bootstrapping | Authoring | Published |
|---|---|---|---|---|
| Haskell | Complete (reference / original bootstrap) | In the main gate (H⇄J⇄P) |
✅ (most modules) | ✅ Hackage |
| Java | Complete | In the main gate (H⇄J⇄P) |
✅ (hydra-java) |
✅ Maven Central |
| Python | Complete | In the main gate (H⇄J⇄P) |
✅ (hydra-python) |
✅ PyPI + conda-forge |
The Haskell/Java/Python triad is exactly the set that gates main: each must generate and test-run the
others before any change lands.
Complete, self-hosting heads (all non-ignored hydra-kernel tests pass), but far less production-tested than the big three and not yet shipped as published releases. Dependable for development and self-hosting; not yet at the Tier-1 "everything green" bar. Scala is expected to reach Tier 1 in the 0.17 cycle (its publishing machinery is ready); TypeScript is in much the same position, only slightly behind Scala (publish-ready, with a host-side stack-limit caveat — it can host every language except Java).
| Language | Head | Bootstrapping | Authoring | Published |
|---|---|---|---|---|
| Scala | Complete | Not yet all-pairs (#409) | ✅ (hydra-scala) |
Ready, not yet (Maven Central, Scala 3) |
| TypeScript | Complete (hosts all but Java — stack-limit caveat) | Not yet all-pairs (#409) | Planned | Ready, not yet (npm — #492) |
| Clojure | Complete (shared Lisp runtime) | Not yet all-pairs (#409) | Planned | Not yet |
| Scheme | Complete (shared Lisp runtime) | Not yet all-pairs (#409) | Planned | Not yet |
| Common Lisp | Complete (shared Lisp runtime) | Not yet all-pairs (#409) | Planned | Not yet |
Full all-pairs bootstrapping for this tier is tracked by #409 (the 8 × 8 everything-to-everything run). The four Lisp dialects share a single coder and runtime.
Earlier-stage work. Emacs Lisp passes the test suite as a target but is still maturing as a host.
A head bud has heads/ runtime scaffolding but the head is still partial (no test runner /
incomplete runtime / not yet test-suite-green); a two-level coder generates types and terms but
has no heads/ machinery, so it is a generation target, not a host. Useful for exploration and
contribution, not for reliance.
| Language | Kind | State |
|---|---|---|
| Emacs Lisp | Conformance target | Passes as target; maturing as a host; shares the Lisp runtime. |
| Go | Head bud |
heads/go/ exists; coder works, runtime partial, not yet test-suite-green. |
| WebAssembly | Head bud |
heads/wasm/ exists; in progress. |
| Rust | Coder (no head yet) | Two-level coder in hydra-ext; no heads/ machinery yet. |
| C++ | Coder (no head yet) | Two-level coder in hydra-ext; no heads/ machinery yet. |
| Coq | In progress | Not yet used. A pure target (see the effects note above), so were it pursued it would be an effect-less head, complete only for the pure subset. |
Typical path: type-level coder → two-level coder → add heads/ machinery (head bud) → passes the
hydra-kernel suite as a target (conformance) → complete head with a test runner and full pass → mutual
bootstrapping with other heads → published artifacts (production) → host-native authoring DSL (the
frontier). The authoring step is orthogonal — a production-supported language need not have it yet —
and is the plan for every language though demonstrated only in Haskell, Java, Python, and Scala today. An
effect-less host (one without I/O) can reach "complete for the pure subset" but, by design, not full
effectful completeness; none is in use today.
The README Implementations table tracks the underlying Complete / In-progress head status that this page interprets. This tier model is descriptive of engineering maturity only; it is independent of the project's branding and 1.0 positioning, which are tracked separately (#495).