Gluon: a statically typed functional language written in Rust for embedding in applications

A language sized for embedding, not for general programs

The one line description in the README is precise about intent: Gluon is a small, statically-typed, functional programming language designed for application embedding. Small is the load-bearing word. This is not a language competing with Haskell or OCaml on generality, it is a language for the part of an application that is awkward to write in the host language and worse to expose as a compiled plugin.

The features list makes that reading concrete. Static typing is justified by a specific problem: writing safe and efficient interfaces between gluon and the host application. Type inference is presented as the reason types rarely have to be written out by hand, giving the benefits of static types with none of the typing. Simple embedding claims marshalling values to and from gluon requires next to no boilerplate, allowing functions defined in Rust to be directly passed to gluon.

The rest of the list covers the details a host application actually cares about. UTF-8 by default, with utf-8 encoded strings and Unicode codepoints as characters. Separate heaps, where each executing gluon thread gets its own garbage collected heap, which keeps each heap small and reduces collector overhead. And thread safety inherited from Rust, allowing multiple gluon programs to run in parallel.

That last claim carries an asterisk in the README, and it is worth keeping in view: parallel execution of gluon programs is described as a recent addition that may still have issues such as deadlocks. A footnote like that tells you more about the current state than the feature bullet does.

Hello world and the import macro that replaces module systems

The smallest program in the README pulls in a module and calls it:

let io = import! std.io
io.print "Hello world!"

The `import!` macro is the mechanism to understand first, because it behaves unlike an import in most languages. The comment inside the 24 game example explains it directly: the macro is used to load and refer to other modules, and it gets replaced by the value returned by evaluating that module. Since the module is cached, multiple `import!`s to the same module only evaluate it once.

That single design choice is what makes the 24 game example readable. Gluon can write `let io @ { ? } = import! std.io` to get the whole module as an open record, or destructure a single name out of it. The example does both, pulling `Result` from `std.result`, `Array` helpers from `std.array`, an integer parser from `std.int`, and individual operator functions from `std.semigroup` and `std.applicative`. Since an import resolves to a regular value, a pattern match is enough to reach into it.

The factorial example shows the type annotations being used sparingly, which is the inference claim in practice:

let factorial n : Int -> Int =
    if n < 2
    then 1
    else n * factorial (n - 1)

factorial 10

Only the function type is written. The recursive call needs no annotation because the annotation on the binding already constrains it.

A do-notation standard library that reads like a scripting API

The 24 game example is the best available tour of the standard library, and it also shows where Gluon sits between ML and Haskell. Parsing is done with `std.parser`, described in the example as a small parser combinator library, assembled with `satisfy`, `satisfy_map`, `token`, `digit`, `recognize`, `chainl1` and the rest of the combinator set.

Effectful code uses `do` expressions, which the example's own comment describes as providing a way to write monads in a way similar to procedural code:

    let integer =
        do i = lex (recognize (skip_many1 digit))
        match int.parse i with
        | Ok x -> wrap x
        | Err _ -> parser.fail "Unable to parse integer"

Randomness comes from `random.thread_rng.gen_int_range`, and the digits are assembled through an applicative `for` imported from `std.traversable`. Aliasing and explicit function syntax are both available: `do digits =` binds, `seq` sequences, and operators are referenced by wrapping them in parentheses, as the evaluator does when it maps `Add` to `(+)` and `Div` to `(/)`.

What this tells a reader is that Gluon has Haskell's type system and notation with the ergonomics of a scripting language. It also tells you the cost: a plugin author has to learn the monad vocabulary to be productive. For an embedded language where a small set of well-known idioms is exactly what you want, that is a reasonable trade, and for a general purpose one it would be a heavy price.

The crate layout, and what a workspace member tells you

The Cargo manifest is the clearest description of the architecture, and it splits the compiler into path dependencies inside the repository:

[workspace]
members = ["c-api", "repl", "completion", "format", "doc", "codegen"]
resolver = "2"

The front end has its own crates: `gluon_parser` for the parser, `gluon_check` for type checking, `gluon_codegen` for code generation, and `gluon_base` for the shared definitions. The runtime is `gluon_vm`, and tooling sits in workspace members, including a C API, a REPL, a completion crate, a formatter, a doc generator and the code generator. The top level crate pulls in the pieces it needs and marks `gluon_vm`, `gluon_format` and `gluon_completion` as ones you can leave out.

The directory tree matches that structure and adds two things worth noting. `vm/` is the virtual machine and `check/` is the type checker, which are exactly the two halves of the embedding story: check code at the boundary, run code in the VM. There is also a `book/` directory, matching the badge in the README that points at the language book published on gluon-lang.org, and an `examples/http/` directory alongside `examples/lisp/` and `examples/marshalling.rs`, so the repository ships a real embedding example rather than leaving it to the documentation.

The manifest is also candid about its dependencies. `salsa` appears as the query engine, pinned through the `gluon-salsa` package name, alongside `codespan`, `codespan-reporting`, `itertools` and `futures`. Edition 2024 in the manifest means the build needs a current Rust toolchain, which is worth knowing before you pin a gluon version in an older codebase.

Separate heaps, UTF-8 strings and the Rust boundary

The two runtime claims in the feature list deserve a paragraph each because they are the ones a host application actually pays for.

Separate heaps: Gluon is garbage collected, but each executing gluon thread uses a separate heap. The stated reason is that it keeps each heap small, reducing the overhead of the garbage collector. In practice this means isolation between concurrently running programs in one process, so one runaway script cannot grow a collector's working set for everything else. That is the design you want for an embedded language where tenants supply code.

UTF-8 by default: strings are utf-8 encoded and characters are Unicode codepoints. For a language that routinely passes user text across a host boundary, having the encoding be a property of the language rather than a library choice removes a class of bug, though it also means a host application with a different convention pays at the marshalling edge.

Marshalling is the piece the README is most confident about, claiming next to no boilerplate and that functions defined in Rust can be directly passed to gluon. `examples/marshalling.rs` exists to demonstrate it, and the book link in the feature list points at an embedding API page for the detail. This is where to look before designing a plugin interface, because the ergonomics of the boundary decide how much of your codebase ends up written in Gluon rather than Rust.

The interface is also documented as available in the standard library under `std.io`, `std.result`, `std.array`, `std.int`, `std.string`, `std.list`, `std.random`, `std.char`, `std.semigroup`, `std.monad`, `std.applicative`, `std.traversable`, `std.parser`, `std.alternative`, `std.prelude` and more, with the `std` crate documented separately on the project site.

Release history, license, and where the project is thin

The version history has a shape worth noting. v0.18.4 was published on 2026-08-06 and matches the last push recorded for the repository, v0.18.3 came on 2026-07-08, and then there is a long gap back to v0.17.2 from 2020-10-25. A pre-1.0 version number with a five year gap in the tag history is an honest signal: the project ships when it ships and is not on a schedule.

The license is MIT, the description in the manifest reads A static, type inferred programming language for application embedding, and the homepage is gluon-lang.org with docs on docs.rs. The repository topics cover compiler, embeddable, functional, language, programming-language, repl, rust and type-inference, which is an accurate summary of the scope.

Where is it thin? The README is not a manual. It gives the feature list, the three examples and links out to the book, the standard library docs and the embedding API page, and it does not document a package manager, a binary distribution story, a compatibility policy for host Rust versions, or how one would ship a Gluon runtime inside a product. The `examples/http/` directory hints at a network story but the README says nothing about it. For a language whose entire purpose is being embedded, that is the documentation you will need to consult before committing, and it lives at gluon-lang.org rather than in this repository.

If your use case is a user-facing language with a compiler you want to run on its own, Gluon is the wrong size. If it is the scripting layer under an application you already control in Rust, the type checker plus the separate heap design is a genuinely good fit for the problem.

Editorial conclusion

Gluon is a scripting language with a compiler attached, and that pairing is the whole appeal for anyone embedding it: `check/` gives you static types across the Rust boundary while `vm/` gives you a runtime that can evaluate what the host passes in. Separate heaps per executing thread and an MIT license make it a defensible choice for a plugin surface. The catch is scope. Gluon is small, and the standard library reaches through `std.io`, `std.parser`, `std.monad` and neighbours, which means you are adopting a standard library's conventions as well as the language. Parallel execution is flagged in the README as a recent addition that may still deadlock, so do not build it into a concurrency model you cannot back out of. Start with `import! std.io` in a host program, then read the embedding API page in the book before designing a plugin ABI.

Frequently asked questions

Official sources

1. gluon-lang/gluon on GitHub
2. License: MIT
3. Project website
4. README
5. Releases