# Google's Rune makes secrets a type the compiler can track

> Rune is an unfinished systems language from Google research that compiles through LLVM, carries values through a database layer that uses ideas similar to DataDraw and gives secret values a dedicated type so comparisons run in constant time. The README says plainly that it is not recommended for any production use case.

**google/rune** — Rune is a programming language developed to test ideas for improving security and efficiency.

- Repository: https://github.com/google/rune
- Stars: 1,934 · Forks: 45
- Language: C
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/google-rune

## A secret type that survives through the call graph

The example the README leads with is a message authentication check, and it contains a bug that most languages let through:

```go
func checkMac(macSecret: secret(string), message: string, mac: string) -> bool {
    computedMac = computeMac(macSecret, message)
    return mac == computedMac
}

func computeMac(macSecret: string, message: string) -> string {
  return hmacSha256(macSecret, message)
}
```

The flaw is a timing side channel on the string comparison. An attacker who can measure how long mac == computedMac takes learns where the first wrong byte is, then brute forces one byte at a time, 256 attempts per byte, until they have forged the whole MAC.

Rune's answer is that the secretness propagates. The parameter is declared secret(string), so the compiler knows the result of hmacSha256 is secret too, and the comparison operator, when either operand is secret, runs in constant time. Note the second function signature: computeMac takes a plain string, not a secret, so the example is showing the propagation from the call site rather than an unbroken thread through the API, which is also a hint that care is still required.

The README is measured about the limits: many common mistakes are detected by the compiler and either fixed or flagged as an error, but users still have to be careful.

## Relation statements generate the code you did not write

The second example is a Human class with optional, self-referential parents. What is interesting is not the syntax but what the programmer does not write.

```rs
relation DoublyLinked Human:"Mother" Human:"Mothered" cascade
relation DoublyLinked Human:"Father" Human:"Fathered" cascade
```

Those two lines are described as being to relation statements what foreign key constraints are in SQL, and they are compared to columns. They drive three separate things.

First, code generation. The methods appendMotheredHuman and appendFatheredHuman that the constructor calls are generated, not written. Second, memory management. Objects the compiler can prove are always in cascade-delete relationships do not need reference counting, which is where the Structure-of-Array allocation story comes from. Third, the destructor, which Rune generates to recursively destroy children, so Rune programmers never write destructors at all.

The example proves the cascade is real rather than decorative. Abel is destroyed and his child Malory disappears with him, so the printed family tree lists Adam, Cain, Alice and Bob, and Eve with the same three, while Abel and Malory are absent.

## Null is in the language but not in the types

Rune has null and still has null safety, which the README explains precisely: null safety here does not mean null does not exist, it means types cannot be null by default.

Optionality is written into the type constraint, as in the Human constructor where mother and father are declared Human? = null(self) with a default. Anything not written that way cannot be null.

That distinction is worth internalising before reading further code, because it inverts the default assumption of a C or C++ programmer. There is no implicit optionality to discover at runtime, and a nullable field has to be visible in the signature where a reader can see it.

## Building it means building DataDraw first

There is no install command in the README beyond a heading pointing at compiling the compiler, so the concrete route is the Dockerfile, which is the most instructive file in the repository.

It starts from ubuntu:23.04 and installs clang-14 as both clang and clang++, plus automake, bison, flex, libgmp-dev and build-essential. It then clones DataDraw from GitHub, runs its autogen.sh, configure and make, and installs it. Rune is cloned next, along with CTTK from the pornin repository, and built with make.

So a Rune build has two external code-generation dependencies before the language itself compiles. That is a real cost for anyone evaluating it, and it also explains the design: DataDraw is the tool that generates optimised C from declarative descriptions of data structures, and Rune integrates its ideas into the language primitives rather than calling it at build time.

The container then runs the test suite and is explicit that some tests are expected to fail:

```dockerfile
RUN echo "TESTING RUNE" \
    && echo 'println "Hello, World!"' > hello.rn \
    && rune -g hello.rn \
    && ./hello \
    && echo "Should have printed 'Hello, World!'"
```

A failing hello world check would fail the image build, which is a decent smoke test for a research language.

## A C compiler with an LLVM backend and three source layers

The Makefile shows what Rune is written in and how it is organised. It is C11, built with -Wall -g -no-pie, linking -lgmp for the bigint library and a DataDraw debug library, producing lib/librune.a and lib/libcttk.a and installing under /usr/local.

The sources divide into three layers that map onto the language design.

The database/ directory is the biggest and holds datatype, class, relation, expression, statement, signature, value, variable and dedatabase among others, which is a layer where data structures and their relationships are described. The transformer/ directory holds constprop.c, iterator.c and memmanage.c, the code transformers that constant-fold, generate iterators and handle memory. The llvm/ directory generates LLVM IR, with genllvm.c and lldatabase.c among the files.

Around that sit parse/, including a deparse.c that turns the database back into source, prettyprint.py as a Python script, plus runtime/, std/, bind/, tests/, errortests/, benchmarks/ and the documentation sources in g3doc/.

Test scripts sit at the root as runtests.sh, runerrors.sh, runl and runll, the last two presumably the compiler and its LLVM variant.

## What it is for, and what it is not for

The README frames Rune as a language developed to test ideas for improving security and efficiency, and that framing is the honest one to adopt. The security claim is concrete, secret values with constant-time comparison. The efficiency claim is Structure-of-Array memory management with automatic removal of reference counting where relations prove it unnecessary, and a stated aim of beating C++ on memory-intensive applications.

Against that, the constraints are clear. The README states it is an unfinished language, invites you to kick the tyres and evaluate the features, and says it is not recommended for any production use case. It is also not an officially supported Google product, which changes what that sentence means for support.

The alternative for the same goals is not another research language but doing the work explicitly in an existing one: constant-time comparison from a vetted crypto library, and relation-style ownership from Rust's ownership model. What Rune offers that neither does is a compiler design where the database is the source of truth and code is generated from it, which is the interesting thing to read.

Licensing is Apache 2.0, so the code can be read, modified and reused under the Apache 2.0 licence, and the last push was on 2026-07-13, three months before today, with no GitHub releases published at all.

## Conclusion

Use Rune to study how a systems language encodes secret values in the type system and how relation declarations feed an optimizer, not as a language to ship code in. The README states outright that it is an unfinished language and not recommended for production, and the Dockerfile itself tolerates failing tests during the build. If you want a systems language to adopt today, this is not one; if you want to read a compiler that generates structure-of-array code and derived accessors, the database/ and transformer/ directories are the interesting part.

## FAQ

### What is the Rune programming language?

Rune is a Python-inspired systems programming language from Google research, written in C and compiled through LLVM, designed to interact with C and C++ libraries. The README states it is an unfinished language and not an officially supported Google product.

### How does Rune protect secrets from timing attacks?

A value can be declared with the secret type, as in secret(string), and the compiler propagates that secretness through the call graph. When either operand of the string comparison operator is secret, the comparison runs in constant time instead of leaking where the first mismatch is.

### What do relation statements do in Rune?

They declare relationships between data structures the way foreign key constraints do in SQL. They generate the accessors such as appendMotheredHuman, they let the compiler skip reference counting for objects provably in cascade-delete relationships, and they generate the recursive destructor, so programmers never write destructors.

### How do I build the Rune compiler?

The Dockerfile shows the route: on ubuntu:23.04 install clang-14, automake, bison, flex and libgmp-dev, build and install DataDraw from its GitHub repository, clone google/rune and the CTTK repository, then run make. Installation goes under /usr/local/rune.

## Sources

- [google/rune on GitHub](https://github.com/google/rune)
- [Issues](https://github.com/google/rune/issues)
- [License: Apache-2.0](https://github.com/google/rune/blob/main/LICENSE)
- [README](https://github.com/google/rune/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/google-rune