Hydra is a strongly typed intermediate language for data, schemas, and code. Programs and domain models written in Hydra map seamlessly to major programming languages like Java, Scala, and Python, to data exchange formats like Protobuf, Avro, and JSON, and to graph data models like RDF and labeled property graphs.
Hydra has been used in production at Microsoft for data modeling, validation, and transforms; its predecessor Dragon drove data integration and graph construction at Uber. Expressive enough to define and compile its own kernel — the core types, functions, and tools which make up the language itself — Hydra is built on the LambdaGraph data model, which establishes an isomorphism between labeled hypergraphs and typed lambda calculus: in Hydra, programs are graphs, and graphs are programs (see The LambdaGraph isomorphism).
- Translingual programming. Write a program or domain model once in a Hydra DSL, using the host language you are most comfortable with, and the same logic becomes available in every other supported language, with test-driven guarantees of semantic equivalence. The Hydra kernel is the most thoroughly exercised example: a working programming language, with its tests, ported across nine languages from a single source of truth.
- Graph construction. Hydra supports TinkerPop-style property graphs as well as RDF and SHACL, and has been used in combination with the ISO/IEC GQL standard. Hydra provides DSLs for defining schemas and mappings, as well as tools for validating schemas and data, and moving them seamlessly into and out of the graph formats.
- Data integration. Hydra includes "coders" (encoders+decoders) for many data and schema languages which you can easily compose together to build data transform pipelines. Some of the currently supported languages and formats include Protobuf, Avro, JSON and JSON Schema, YAML, RDF formats including N-Triples, GraphQL, and simple tabular data (CSV/TSV).
- Computational graphs. As an ontology language, Hydra has deep support for parametric polymorphism, as well as embedding of computational elements within a graph (sometimes called computational knowledge graphs). This follows naturally from the programs-are-graphs framing. See the KGC 2024 presentation Graphs, logics, and lambda calculus for examples.
Hydra's most distinctive properties come from its graph foundations, and from being a single programming language kernel that runs natively in multiple host languages. Its ability to translate any valid program -- including its own kernel -- into any supported language distinguishes it from conventional polyglot tooling. (A host language is one in which Hydra runs natively, and in which you can write Hydra programs; a target language is one into which Hydra generates code. Every host is also a target.)
Hydra is mutually self-hosting: starting from any one of its current implementations, the kernel can be regenerated into another host language, and that regenerated implementation can in turn regenerate the first — without dependency on the original source language. Nine implementations have this property today — Haskell (Hydra's original bootstrapping language), Java, Python, Scala, TypeScript, and four dialects of Lisp (Clojure, Scheme, Common Lisp, and Emacs Lisp) — and all of them pass the hydra-kernel test suite under every bootstrapping path. TypeScript, Emacs Lisp, and (like Scala and Lisp) the JVM Lisp dialects self-host in the two load-bearing pillars — running as a codegen target and as a codegen host — but do not yet author Hydra DSL sources in their own language; only Haskell, Java, Python, and Scala do all three today. Additional ports are in active development; see the Implementations table below for the full set.
The hydra-kernel test suite is what makes translingual programming load-bearing rather than aspirational: it ensures every program behaves the same when translated into each supported language, which is essential in heterogeneous environments where the same logic must be manifested identically across more than one programming language. Examples where this is useful are Gremlin language variants in Apache TinkerPop, where the same queries/programs need to produce identical results against the same data in different runtime environments, database clients which expose the same API and validation logic in different languages, and heterogeneous distributed systems.
Hydra has an independent, implementation-agnostic specification: the normative,
implementer-facing reference for the language — the data model, textual syntax, type
system, validation, the standard primitive library, and the interchange formats. It
states what a conforming implementation MUST do, and is the reference against which all
of the heads above are measured (no single implementation is "the reference"). It is
distinct from the explanatory wiki and
the implementation-facing docs/ tree.
The specification is a work in progress (currently Draft):
- Specification index — scope, conformance, versioning, and table of contents
- Textual syntax — the syntax of terms, types, and their dependencies
Hydra publishes to Hackage (Haskell), Maven Central (Java and Scala), PyPI and conda-forge (Python), and npm (TypeScript). All Hydra packages share a single version number.
The Releases wiki page is the authoritative, always-current list of published packages and their registry locations for the latest release. See the CHANGELOG for release history and the release policy for how releases are versioned and published.
Hydra is preparing for its 1.0 release, with the intention of becoming an Apache Incubator project and integrating more directly with Apache TinkerPop and other projects in the Apache ecosystem. The last few releases have focused on production-hardening and forward compatibility.
A Hydra head is the mapping of the Hydra kernel into a host language, together with the primitive functions and bootstrapping infrastructure required to make Hydra a complete programming language on that host. Each head is an independent point of entry to Hydra: you can pick the head you're most comfortable with and ignore the others.
For how well-supported each language is — a support-tier model (production-supported / conformance target / experimental head bud) graded on test-suite pass, self-hosting, runtime completeness, authoring, and published artifacts — see Language support on the wiki.
| Head | Status | Description |
|---|---|---|
| Haskell | Complete | Complete implementation and a build host: the kernel DSLs are authored in Haskell and Hydra code-generates itself from them, so Haskell both self-hosts and drives the build. Published to Hackage. |
| Java | Complete | Complete implementation and a build host: self-hosts and its native coder generates Hydra into the JVM. Published to Maven Central. |
| Scala | Complete | Complete implementation and a build host: self-hosts on the JVM and its native coder participates in the build. Published to Maven Central. |
| Python | Complete | Complete implementation: self-hosts and passes the hydra-kernel test suite. Published to PyPI and conda-forge. |
| TypeScript | Complete | Complete implementation: self-hosts and passes the hydra-kernel test suite. Published to npm. |
| Clojure | Complete | Complete implementation: self-hosts on the JVM and passes the hydra-kernel test suite. Shares the Lisp-family coder. |
| Common Lisp | Complete | Complete implementation: self-hosts and passes the hydra-kernel test suite. Shares the Lisp-family coder. |
| Scheme | Complete | Complete implementation: self-hosts and passes the hydra-kernel test suite. Shares the Lisp-family coder. |
| Emacs Lisp | Complete | Passes the hydra-kernel test suite as a target; still maturing as a self-hosting host. Shares the Lisp-family coder. |
| Go | In progress | A "head bud": kernel code generation works, but the hand-written Go runtime is still stubbed out and Go does not yet host the test suite. |
| Rust | In progress | Generation target; the coder lives in hydra-ext and has not yet been split into its own head package. |
| C++ | In progress | Generation target; the coder lives in hydra-ext and has not yet been split into its own head package. |
| Coq | In progress | Generation-only target: Hydra emits Coq, but there is no Coq-side runtime. |
| WebAssembly | In progress | Generation-only target: an experimental WebAssembly coder with no host-side runtime yet. |
A Hydra package is a unit of DSL source code organized around a coherent area of functionality. Most packages are language-independent (described in a DSL, generated into every supported host); a few are domain models that build on the kernel.
| Package | Purpose |
|---|---|
| hydra-kernel | Core types, terms, type inference, validation, primitives, and the coder framework. Every other package depends on this. |
| hydra-ext | Extension coders: Avro, Protobuf, GraphQL, Pegasus/PDL, JSON Schema, YAML, SQL, C++, Rust, Csharp, plus domain models. |
| hydra-pg | Property-graph model and coders (GraphSON, Cypher, GQL, TinkerPop, Graphviz, RDF mappings); the PG validator; a Neo4j model with client-side validation and a property-graph mapping. |
| hydra-rdf | RDF 1.1, SHACL, OWL 2, ShEx, and XML Schema syntax models; N-Triples serialization. |
| hydra-bench | Synthetic inference benchmark workloads. Opt-in: not part of default sync. |
| hydra-haskell, hydra-java, hydra-python, hydra-scala, hydra-lisp, hydra-typescript, hydra-go, hydra-coq, hydra-wasm | Per-language coder packages (DSL sources for translating Hydra modules to each target). See the Implementations table for head status. |
Host-specific integrations that connect a Hydra package to an external system — and other hand-written,
language-specific source — live under overlay/<lang>/<pkg>/ and are copied onto the generated
distribution package. (These were formerly a separate bindings/ tree; folded into overlays in #511.)
See docs/overlays.md for how the overlay system works.
| Integration | Where | Purpose |
|---|---|---|
| Eclipse rdf4j | overlay/java/hydra-rdf (README) |
RDF serialization via rdf4j Rio for hydra-rdf. |
| Cypher / GQL parsers | overlay/java/hydra-pg (README) |
ANTLR-based openCypher/GQL parsers, converting to hydra.pg.query.*. |
| TinkerPop / Gremlin | overlay/{java,python}/hydra-pg (README) |
Hydra ↔ Gremlin bytecode + pg ↔ TinkerGraph bridge. |
| PG DSL builders | overlay/java/hydra-pg (README) |
Java fluent builders (Graphs, Queries, Merging) for hydra-pg. |
Questions, ideas, or something not working? Join the Hydra Discord (the LambdaGraph community server) or open a GitHub issue.
- Getting started — using Hydra as a library from your own project.
- DSL guide — writing Hydra programs and domain models using the embedded DSLs. See also the Java and Python variants.
- Demos — runnable demos illustrating Hydra's capabilities, with input data and expected output.
- Troubleshooting — common failure modes and how to diagnose them.
- Concepts — core type system, terms, modules, and design principles.
- Property graphs — Hydra's hypergraph foundation and its relationship to TinkerPop-style property graphs.
- RDF support — modeling, validation, and emission for RDF, SHACL, and related semantic-web formats.
- JSON format — the language-neutral interchange format for kernel modules.
- Contributing — starting point for contributors: setup, expectations, testing, and PR guidance.
- Contributor setup — toolchain prerequisites, tiered by scope (kernel only / triad / full matrix).
- Implementation guide — architectural deep dive into kernel modules, DSLs, primitives, and coders.
- Code organization — the
packages/,heads/,overlay/, anddist/layout. - Coding style — guiding principles, ordering conventions, common mistakes.
- Developer recipes — step-by-step guides for adding primitives, extending core types, refactoring, and similar tasks.
- Build system — pipeline phases, caching layers, and what triggers regeneration.
- Hydra Discord — the LambdaGraph community server.
- HydraPop — translingual property-graph and TinkerPop validation extensions for Hydra (Java + Python).
- Introductory blog post by G.V (Amber Lennox).
- Earlier presentations: Transpilers Gone Wild, and a longer technical deck.
- The original design document.
- LinkedIn demo series (oldest to newest):
- Hydra property graph demo (Part 2).
- Translingual programming demo from Data Day Texas.
- Bootstrapping demo — mutual self-hosting across three languages.
- Graph validation in any language — applying Hydra's validation logic identically across host languages.
Hydra is open-source software licensed under the Apache License 2.0.