-
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 three languages:
- Haskell — the original authoring language; most kernel and package modules have Haskell-based sources.
-
Java (
hydra-java) and Python (hydra-python) — their coder DSL sources are authored host-natively (in Java and Python), 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.
Two-level coder; a complete head (all non-ignored hydra-kernel tests pass); the language can be used to build and run Hydra in production. Bootstrapping reach and published artifacts vary across the tier (see the columns) — not every Tier-1 language is published yet, but each has a complete, dependable head.
Two of the columns capture a distinction worth stating plainly: "Authoring" is host-native DSL support for writing Hydra sources (the frontier — planned everywhere, demonstrated in H/J/P only); "Published" is whether versioned release artifacts actually ship for that language today (published / ready, not yet published / not yet).
| 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 |
| Scala | Complete | Not yet all-pairs (#409) | Planned | Ready (machinery in place; not yet published — Maven Central, Scala 3) |
| 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 |
Published releases exist today for the big three only — Haskell, Java, and Python. Scala's publishing machinery is ready and its packages are expected to ship in the 0.17 cycle; TypeScript (Tier 2) is likewise publish-ready. The Lisp dialects are not yet published.
Only the Haskell/Java/Python triad is guaranteed to mutually bootstrap (it gates main). The other
Tier-1 languages have complete heads but do not yet bootstrap every other head;
#409 (the full 8 × 8 everything-to-everything
run) is closing those gaps. The four Lisp dialects share a single coder and runtime.
A two-level coder whose head passes the hydra-kernel test suite as a target (generated code is correct), but which is not yet fully production-supported — self-hosting/bootstrapping reach is incomplete, the runtime is still maturing, or artifacts are only now reaching a registry. Safe to generate to; not yet a drop-in production host for all paths.
| Language | Head / test status | Notes |
|---|---|---|
| TypeScript | Passes as target | Can host every language except Java (stack-limit caveat); npm publishing ready, not yet published (#492) |
| Emacs Lisp | Passes as target | Maturing as a host; shares the Lisp runtime |
Two kinds of early work sit here. A two-level coder generates both types and terms but has no
heads/ machinery — it is a generation target, not a host. A head bud adds the heads/ runtime
scaffolding but the head is still partial: no test runner, an incomplete runtime, or not yet
test-suite-green. Both are useful for exploration and contribution, not for reliance.
| Language | Kind | State |
|---|---|---|
| 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, and Python 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).