Hydra

Hydra is a strongly typed intermediate language for data, schemas, and code. Programs and domain models written in Hydra map directly 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).

Use cases

• 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 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.

Translingual features

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 as both codegen target and 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 real 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.

Specification

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

Releases

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.

Status

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.

Implementations

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.

Packages

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.

Host-native overlays

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.

Getting help

Questions, ideas, or something not working? Join the Hydra Discord (the LambdaGraph community server) or open a GitHub issue.

Resources

Getting started and using Hydra

• 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, Python, and Scala variants.
• Demos — runnable demos illustrating Hydra's capabilities, with input data and expected output.
• Troubleshooting — common failure modes and how to diagnose them.

Concepts and design

• 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.

For contributors

• 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/, and dist/ 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.

Talks, demos, and community

• 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.

License

Hydra is open-source software licensed under the Apache License 2.0.