Valen's new borrow checker allows multiple mutable references to one object

The author of a long blog post introduces the new borrow checker in Valen, a language that blends ideas from the author's earlier language Vale. The post is part of what the author calls an eternal quest for a memory safety holy grail: something as powerful as Rust's borrow checking, yet as simple and flexible as reference counting or garbage collection. The author has long suspected that three memory-safety challenges would have to be solved to get there. This post focuses on the first, a more relaxed borrow checker, and on what it is, what it can do and how it works. One of the other challenges, reading more complex data (immutable borrow references pointing into arbitrary graphs of objects, as in C++ or Java), is answered, the author says, by Vale's blend of generational references and region borrowing.

Valen's approach is built on the Group Borrowing proposal designed by the author's friend Nick Smith. The core idea is that the compiler remembers where a reference points to, because the user states it with the in keyword, and uses that to check that the program is memory safe. The author recounts that the design nearly died: it was originally made with Mojo in mind, but the author could not convince the 'higher-ups' to adopt it. So the two spent months sharpening the explanation and wrote a post on it last year, hoping other languages would pick it up. According to the author, they did, and many of those languages are circling the same problem: how to make a more flexible borrow checker. Valen wants one that works with reference counting and generational references; Carbon wants one that works with C++ code. Zeta's borrow checker, the author adds, can prove that two references point to different parts of the same data, for example list.get_mut(i) and list.get_mut(j) when i != j, even if both indices are runtime values.

The obstacle is a fundamental conflict between borrow checking and other approaches, which the author once called 'the language killer' because it destroyed many versions of many experimental languages, including one of Vale's earlier approaches. One of those was 'hybrid-generational memory', where a reference could be kept alive by tethering a generational reference for the duration of a scope; the author went through thirty two versions of it before giving up. Group borrowing, the author claims, resolves the conflict by relaxing 'shared-xor-mutable' to 'no use-after-free'.

The post then shows what that means in code. In one example, a program takes a reference to the first element of a vector inside a World struct, then replaces the vector; the compiler rejects the final read with 'Used a borrow after invalidated'. In another, a program makes two references to the same list and pushes to it through both, which many compilers refuse; the author says this approach understands it is safe. Normal borrow checkers forbid two read-write references to one object, but group borrowing guards specifically against use-after-free, so it does not. The author lists patterns it accepts that are hard elsewhere: a single unique_ptr-style owner with many long-lived raw pointers to the object (the C++ habit), a ScopeGuard object holding a reference alongside the code that uses the object directly (a possible basis for a user-defined defer statement), and several File objects each holding a reference to one common FileSystem object.

The main comparison is a step function that advances an entity inside a world, asks the world for the collision for that entity, then resolves it. In C++ it is simple, but memory safety is the programmer's job. In Rust it needs an entity ID and three separate lookups, each with a bounds check and possible panic, because the mutable reference has to be re-fetched each time something else in the same hierarchy needs a &mut. Refactoring to a 'flatter' layout has its own trade-offs, and the GhostCell version needs brands and a GhostToken. In Valen the signature is func step(world &World, entity in world.entities[] mut), and the body reads like the C++ one. The in world.entities[] mut part says that entity refers to one of the world's entities and may be modified. The author stresses this is not like Rust's unique &mut: other references to the same entity can exist.

On the current state, the author notes that Valen and Vale both have linear types and mostly share syntax, though Valen might move toward a 'simpler Rust' look. In today's compiler, users must dereference manually, index arrays directly like my_vec.data[0], and put types on all parameters, which the author shrugs off as life when working on someone else's language. The author says a follow-up article will compare how all these languages' approaches work, and states that none of this post was written by AI.

Key facts

Valen's new borrow checker is built on the Group Borrowing proposal designed by Nick Smith, a friend of the post's author; the compiler tracks where each reference points, declared with the in keyword.
The author claims it catches use-after-free errors at compile time with fewer restrictions than previous approaches, and with no run-time cost, while conceding it is debatable whether any language can reach zero-overhead memory safety.
It accepts multiple read-write references to one object, such as two refs pushing to the same list, which normal borrow checkers reject under shared-xor-mutable.
In the entity-step example, C++ and Valen look nearly identical, while the Rust version needs an entity ID and three bounds-checked lookups, or GhostCells with a token.
The author says Group Borrowing began as a design for Mojo, was not adopted there, and was later picked up by other languages, with Carbon and Zeta named in the post.

Why it matters

Rust's borrow checker gives compile-time memory safety but is strict: shared-xor-mutable rules out patterns that are routine in C++, Java or code using reference counting. The post's central claim is that Group Borrowing relaxes that rule to 'no use-after-free', so the compiler checks only the thing that actually causes the bug. If that holds up, it would let safe code keep long-lived references and several mutable references to the same object. The author also frames this as a live design question across several young languages: Valen wants a checker that works with reference counting and generational references, Carbon wants one that works with C++ code, and Zeta tracks disjoint parts of the same data.

Who it affects

Mainly designers and implementers of programming languages and compilers, who are the audience the author hoped to reach with the original Group Borrowing post. It also speaks to programmers who move between C++ and Rust and run into the re-fetching and ID-indexing patterns the post describes. The author notes that Rust structs can hold references to other structs only temporarily, which is why ECS is a popular choice in Rust games. For anyone trying Valen, the post describes today's compiler as needing manual dereferencing, direct array indexing and typed parameters.

How to use it

There is nothing to install from the visible text of the post, and it does not say whether Valen is released, stable or usable by the public. What the post offers is a way to read the design: the in annotation, as in entity in world.entities[] mut, tells the compiler which container a reference points into, and the compiler uses that to reject only genuine use-after-free. The side-by-side C++, Rust, GhostCell and Valen versions of the step function are the quickest way to see the difference. The author points to an older post, 'Group Borrowing: Zero-Cost Memory Safety with Fewer Restrictions', and calls the new one a much better explanation.

How solid is it

This is one author's design essay, and every claim in it is the author's own. It gives code examples and comparisons but no benchmarks or performance measurements, only the claim of no run-time cost. The author himself concedes that it is debatable whether any language can get memory safety with zero run-time cost, and points to a piece titled 'Chasing the Myth of Zero-Overhead Memory Safety', saying it applies to group borrowing too. The author also hedges on the larger goal: Valen 'might have' solved the remaining challenges by blending Vale's approach, a thought experiment from 2023, Group Borrowing and a few twists, and only hints at this. The part of the post that explains the mechanism was not available, so this account rests on the examples and comparisons. The author says none of the article was written by AI.

Risks and caveats

The author calls the goal controversial: some believe a reference's referent should never change out from under you, while an ID's or index's referent may (as in Rust); others find that too restrictive. The author thinks the user should be able to choose. The zero-cost claim is openly debated, by the author's own account. Valen's syntax may still change toward a 'simpler Rust', and the current compiler needs manual workarounds the author attributes to working on someone else's language. Group Borrowing was designed with Mojo in mind but was not adopted there, so its track record rests on the languages that took it up later.

“It catches use-after-free problems at compile time, and it does it in a way that has less restrictions than previous approaches.”

— The post's author, on Group Borrowing