Valen: a memory-safe language that borrows Rust's borrow checker and relaxes it

Group borrowing is the idea the whole project rests on

Valen is described as a programming language that aims to be not only fast and memory-safe, but also easy and flexible. The safety half of that comes from a specific technique, and the technique is what makes the project interesting.

For memory safety and data-race safety it uses group borrowing, described as a technique like a more flexible borrow checking, with mutable aliasing. The linked explanation is a blog post on the same site as the language's own lineage, so the design is written up rather than implied.

Rust's rule is the one being relaxed. Rust gives you either one mutable reference or any number of shared ones, and the compiler tracks that through a lifetime graph. Group borrowing keeps the data-race guarantees but allows mutable aliasing within a group, so a group of references can all point at the same thing and be written to, as long as the group is treated as a unit.

That is the trade the language is making. Strict aliasing buys you a simple mental model. Relaxing it inside a group buys you flexibility, and you pay for it with a more complicated model that you have to learn. The plans section says generational references and reference counting will be added, and that those should be usable without Cell, RefCell and the rest, which is the same argument made a different way: interior mutability is a common need, and the language would rather give you a first-class mechanism than make you reach for a runtime-checked cell.

The ecosystem claim is the other half of the pitch. Valen is able to call into existing Rust libraries, and the speed claim is that it is AOT compiled to LLVM, statically typed, and aims to be the fastest safe language, by giving more fine-grained aliasing information to LLVM.

Building the compiler is a normal cargo build, and that is the easy path

The steps to run a Valen program are laid out as a numbered list, and the first half is straightforward enough to follow exactly.

Build the compiler by cloning the repository and building the binary:

git clone https://github.com/valen-lang/valen ~/valen
cd ~/valen
cargo build --bin valec

Then make a project directory, create a src directory inside it, and put a src/main.valen in place containing exported func main() int { return 42; }. Then compile and run:

~/valen/target/debug/valec build --no-std --builtins-dir-override ~/valen/src/builtins/resources main=src
build/main

The result is checked with echo $?, which should print 42.

Two flags in the compile command carry most of the meaning. The --no-std flag says to compile without the standard library, and --builtins-dir-override points the compiler at the builtins resources directory inside the cloned repository, which is where the compiler finds the intrinsic definitions it needs when the standard library is switched off.

The main=src argument is the entry point specification, giving the module path rather than a file. The output lands in build/main, so the compiler emits a runnable binary in the build directory.

This path is the one you want if you are evaluating the language. It needs only a Rust toolchain and produces a working compiler with no extra machinery.

Calling Rust libraries means building a patched rustc from source

The interop path is a different undertaking, and the documentation is careful to warn about it.

The warning is explicit: this is a version of rustc that the project modified, it is not the official rustc. The fork lives at the valen-lang/rust repository, and the branch to check out is per-instance-mir, described as the branch with the rustc patches. Then a config.toml has to carry two settings:

[llvm]
download-ci-llvm = false
link-shared = true

Those two lines disable the prebuilt LLVM download so the local LLVM is used, and link the shared library so the compiler can be linked against it.

The build itself is a two stage rustc bootstrap, ./x build followed by ./x build --stage 2, and then the result is registered as a toolchain with rustup toolchain link rustc-for-valen ~/rust/build/host/stage1, plus a symlink so the stage1 cargo is found. The compiler is then built against that toolchain with the rust_interop feature:

cargo +rustc-for-valen build --features rust_interop --bin valenc-rs --bin valen

A project then declares its Rust dependencies in a Valen.toml manifest, in a TOML format with a project section carrying a name, version and edition, a rust-dependencies section listing crates, and a bin section naming the binary and its source:

[project]
name = "test_project"
version = "0.1.0"
edition = "2021"

[rust-dependencies]
chrono = "0.4"

[[bin]]
name = "main"
source = "src/main.valen"

And the Valen source imports the crate directly, with import chrono.TimeDelta, then calls TimeDelta.seconds(42i64) and returns d.num_seconds(). Compiling that project requires the patched compiler on the path via the COMPANION_RUSTC environment variable pointing at rustup which for the rustc-for-valen toolchain, and the resulting binary lives under target/valen-build/target/debug/main.

The cost of all this is the real story: to call a Rust crate from Valen you build a modified Rust compiler from source, twice.

The Cargo manifest shows where the compiler actually lives

The repository's Cargo.toml is unusually revealing about how the project is put together, and it is worth reading as design documentation rather than as packaging metadata.

The package is named frontend_rust, version 0.1.0, edition 2021, with a build.rs and links set to vale_backend. The links key is the Cargo mechanism for a build script that produces a native library, which tells you the Rust frontend is not self-contained: there is a C++ backend that it links against, built through cmake as a build dependency.

The feature list is where the experimental surface is visible. rust_interop enables Rust interop and the comment says to take it out to get a standalone Valen compiler. anonymous_substruct is on its own. horizon depends on both rust_interop and anonymous_substruct. borrow_checker_experimental stands alone. And no_backend runs all the tests without the C++ backend, with a comment saying to delete this soon.

That last comment is a good indicator of the project's state. A feature whose purpose is to let the test suite run without the real backend, marked for deletion, is exactly what you would expect from a compiler that is barely past the proof-of-concept stage.

The binaries are listed with their required features. valec is the ordinary compiler at src/bin/valec/main.rs. valenc-rs is the Rust interop driver at src/typing/rust_interop/driver/main.rs and requires rust_interop. valen is the interop-aware compiler at src/typing/rust_interop/valen/main.rs and also requires rust_interop.

The runtime dependencies are the usual compiler-building set: bumpalo for arenas, indexmap and hashbrown for ordered and fast hash maps, rustc-hash, paste for macro metaprogramming, clap with derive for the command line, serde with derive for the manifest, and toml for parsing Valen.toml. A profiling profile inherits release and turns on debug info.

The top-level tree matches that structure, with a Backend/ directory for the C++ side, src/, stdlib/, tests/, examples/, build.rs and a scripts/ directory. The examples directory is where the interop experiments live, with borrow_check_over_rust_boundary, mutable_aliases_over_rust_boundary, mutable_aliases_pure_valen and use_rust_chrono_lib.

Where Valen is the wrong tool

The first limit is stated before anything else in the project documentation. Valen is still a prototype and barely past the proof-of-concept stage. There are holes and sharp edges, and String and HashMap require some more Rust interop work. After a few months of solidifying and stabilizing there will be a 0.1 version that is nice and usable for basic cases.

That paragraph is the honest summary, and it should be read as a description rather than a caveat. There is no 0.1 release, and there are no GitHub releases either, so there is nothing to pin to. The repository is not archived and the last push was on 2026-10-18, so work is happening, but the line you would depend on is a moving prototype.

The second limit is the cost of the interop path, and it is high enough to change who can evaluate the project. Building the patched rustc means cloning a compiler fork, configuring a non-default LLVM setup, running a two stage bootstrap, and registering a custom rustup toolchain. That is a day of work for a machine that does not otherwise need a Rust development environment beyond a normal cargo build, and it is a prerequisite for the feature the language's ecosystem story depends on.

The third is that the speed claim is a target rather than a measurement. The language aims to be the fastest safe language by giving LLVM more fine-grained aliasing information, and there is no benchmark in the repository comparing it against anything. The same applies to the flexibility claim, which is about generational references and reference counting that the plans section says will be added.

The fourth is the relationship to the past. Valen is the successor to the Vale programming language, and the historical notes are explicit that Vale existed because of its sponsors and Valen exists because Vale existed. That history is a strength in one sense, since the design decisions have a documented lineage through the linked blog posts, and a warning in another: a language that has already been through one redesign cycle before reaching 0.1 may go through another.

The fifth is that the compiler itself is a hybrid. The Rust frontend links against a C++ backend through a cmake build step, and the no_backend feature exists only so the test suite can run without it. That is an unusual shape for a language implementation, and it means the build has two toolchains and a native library boundary, which is more moving parts than a self-hosted compiler would have.

Editorial conclusion

Valen is worth reading if you are studying ownership and aliasing models or you want to see what a borrow checker looks like when the same-mutable-reference rule is relaxed, because the group borrowing technique and the companion blog posts explain the design decisions rather than just shipping them. It is the wrong tool for production work, and the project says so in the first paragraph. Before you try it, check the three things that decide whether you can even run it: that Valen is still a prototype with holes and sharp edges, with String and HashMap needing more Rust interop work and no 0.1 release yet; that building it needs a patched rustc rather than the official one, which means compiling rustc twice from a fork on the per-instance-mir branch; and that the interop path requires the rust_interop feature, so a stock cargo build produces a compiler that cannot call into Rust crates.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. valen-lang/Valen on GitHub