Rue compiles to machine code without LLVM, and its build system is Buck2 rather than Cargo

Higher level than Rust, lower level than Go, and neither exactly

Rue is an experimental systems programming language exploring memory safety without garbage collection and higher-level ergonomics than Rust or Zig. It is implemented in Rust and emits native code directly, without LLVM.

The repository description phrases the ambition as a programming language that is higher level than Rust but lower level than Go, and the README adds Someday, anyways, which sets the tone honestly. This is a language design project, not a product.

The caution notice in the README is worth reading exactly as written. Rue is an early-stage language, and its syntax, semantics, runtime and standard library are still changing, and it is not ready for production use.

The example in the README shows what the language looks like today.

fn fib(n: i32) -> i32 {
    if n <= 1 { n } else { fib(n - 1) + fib(n - 2) }
}

fn main() -> i32 {
    @dbg(fib(10));
    0
}

Two things stand out. The `if` is an expression whose value is the branch, so `n` is returned without a return statement, and `main` returns `i32` where the value becomes the process exit code. The `@dbg` form is a debug print macro with an at sign, which is a common convention in newer languages and reads well next to the expression style.

The licence is dual, Apache 2.0 or MIT at your option, with both licence files in the repository root, and contributions are dual licensed on the same terms unless stated otherwise. The default branch is `trunk` rather than `main`, which is a Rust convention that has spread, and the homepage is rue-lang.dev.

A whole compiler pipeline, and the parts that are unusual

The list of what is in the repository reads like a compiler's table of contents.

There is a lexer, a parser, semantic analysis, and several inspectable IRs. The type system includes affine ownership, borrowing modes, destructors, structs, enums, arrays, strings, modules, comptime, and unsafe and raw-pointer support. The code generation covers x86-64 Linux, AArch64 Linux and AArch64 macOS. There is a small runtime, ELF and Mach-O object and linking support, and direct machine-code emitters. And the test infrastructure includes specification, UI, CLI, differential-oracle, fuzz, sanitizer and stress suites.

The word inspectable in the IR description is the interesting part. An inspectable intermediate representation means you can look at what the compiler produced, which is a precondition for the differential-oracle testing the repository lists. You cannot fuzz a compiler and diff the results unless you can serialise the intermediate states, so the two features are connected.

The differential oracle is the notable test strategy. A differential oracle is a second implementation, ideally written differently, that you compare against. For a compiler whose output is machine code, the oracle has to be something that knows the right answer independently, which is hard but possible for a subset of the language, and the presence of the suite says the author is doing it.

The combination of fuzz, sanitizer and stress suites is the standard trifecta for a native code generator. Fuzzing finds crashes in the compiler, sanitizers find undefined behaviour in the compiler's own code, and stress suites find the resource exhaustion bugs that fuzzing often misses.

The authoritative language definition is the Rue specification under `docs/spec/`, and the tutorial is the best introduction to writing Rue programs. The design rationale lives in `docs/architecture.md` and `docs/designs/`.

Buck2, Dotslash and a hermetically bootstrapped build

The build system is the most unusual thing about the repository, and it is worth understanding before you try anything.

Rue uses Buck2 rather than Cargo. You install Dotslash, and Buck2 and the Rust toolchain are then bootstrapped hermetically by the repository. The word hermetically is the important one: the build does not depend on what happens to be installed on your machine, it brings its own.

scripts/rue build
scripts/rue exec examples/welcome.rue   # prints 1, 2, 3, 42 and exits 0
scripts/rue test

The `scripts/rue` wrapper is the entry point for the common operations, and the README explains why the health check example is `examples/welcome.rue`. It prints recognizable output and exits 0, so a successful run is not mistaken for a failure under `set -e` or in CI. The note contrasts this with programs like `examples/fibonacci.rue`, which return a value from main, which becomes the process exit code, and that is informative but a nonzero status.

That is a small piece of operational care that says a lot about how the project is run. A build system where the first thing you do is install a tool whose purpose is to make binaries hermetic, and where the smoke test is designed to be unambiguous under a strict shell, is a project that expects to be built in CI and by people who did not write it.

The repository root shows the tooling in full. There is a `.buckroot`, a `BUCK` file, `buck2/` and `buck2-bin/` directories for the toolchain, a `buck2` binary wrapper, `reindeer` and `btd` directories, `constraints/` for dependency pinning, `corpus.bzl` and `test_defs.bzl` and `test_tiers.bxl` for the test definitions, `toolchains/` and `platforms/` for the target definitions, and `third-party/` for vendored dependencies. The `rust-toolchain.toml` and `rustfmt.toml` files pin and format the Rust side, and `clippy.toml` configures the linter.

The target list is short, and the examples show the language's range

Supported targets are `x86-64-linux`, `aarch64-linux` and `aarch64-macos`. Cross-target machine-code and assembly emission is available, but producing an executable may require target-specific system tools.

That last sentence is the honest limit of a native backend with no LLVM. Emitting machine code for a target is one thing, but producing a linked executable needs a linker, a C library and the target's system libraries, and those are not portable artefacts. A compiler that goes through LLVM gets much of that for free because the target description carries it.

The `examples/` directory is the best available evidence of what the language can express, and the list is instructive. There is `hello.rue`, `fibonacci.rue`, `fizzbuzz.rue`, `collatz.rue`, `gcd.rue` and `floats.rue`, which are the usual smoke tests. Then there are `arrays.rue`, `binary_search.rue`, `bst.rue`, `generics.rue`, `generic_stack.rue` and `heap.rue` for the data structures and generics. Then algorithm shaped ones, `dijkstra/`, `lattice/`, `hashmap/`, `bignum/` and `dup/`. Then programs that look like real software, `calculator/`, `jsonfmt/`, `gazette/`, `caldera/` and `harbor/`. And `dbg.rue` for the debug macro.

A `dup` example is a small signal. In a language with affine ownership, duplicating a value is a semantic question rather than a copy and paste, and having an example dedicated to it suggests the author has thought about where the linear type rules have to bend.

The `std/` directory holds the standard library, the `crates/` directory the Rust implementation, and the `website/` directory the documentation site, which is built with Zola and Hugo according to the root entries, with tailwindcss also vendored. The `performance/` directory suggests performance work is tracked, and `reproducibility/` suggests that reproducible builds are a goal rather than an accident.

Developed in public, including as an agent engineering experiment

The project status section is short and it contains the most distinctive claim in the repository.

Rue is developed in public as both a language-design project and as an experiment in agent-assisted compiler engineering. Accepted features may remain behind `--preview` until their implementation and specification are complete. And the test suite tracks normative specification coverage and known implementation gaps explicitly.

That last sentence is the one that matters for anyone reading the code. A language that has a specification and tracks how much of that specification the implementation actually covers is doing something quite rare: it makes the gap between design and implementation measurable. A language without a spec can only tell you what the compiler happens to do today, which is a moving target.

The `accepted but behind a flag` policy is a reasonable compromise. It lets a design be agreed in the spec and in the review process before the implementation is finished, without pretending the feature is done, and the `--preview` flag is the mechanism a user has to opt in explicitly.

The repository is set up for agent-assisted work. There is an `AGENTS.md` and a `CLAUDE.md` at the root, a `.claude/` directory, and the tooling around the build is scripted in `scripts/`. The presence of `gen-rust-project.sh` suggests part of the Rust implementation is generated, which is consistent with the claim that this is an experiment in agent-assisted compiler engineering rather than a claim about the language's design alone.

The contribution and development workflow is documented in `CONTRIBUTING.md` and `docs/development.md`, and there are quick test scripts, `quick-test.sh` and `test.sh`, alongside the `fmt.sh` formatting helper and a `reproducibility/` directory.

Editorial conclusion

Adopt Rue only as a research subject, or as a way to follow how a language is designed and specified from scratch, since the README states it is not ready for production use and that its syntax, semantics, runtime and standard library are still changing. Do not adopt it for anything you have to maintain. Verify first that the language specification in docs/spec matches the behaviour of the compiler you build, that accepted features you rely on are not still behind the --preview flag, and that your target is one of the three supported ones, since producing an executable for a different target may need platform specific system tools.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. rue-language/rue on GitHub