The Golden Spike, and Resurrecting the Vale(n) Programming Language

“黄金道钉”与 Vale(n) 编程语言的重生

Let’s do something ridiculously ambitious and very inadvisable. 让我们做一件极其宏大且非常不明智的事情。

Sep 17, 2026 — Evan Ovadia 2026年9月17日 — Evan Ovadia

There was an incredible moment on May 10th, 1869, when railroad builders finally reached their goal of joining the east coast rail network with the west coast rail network. In that moment, the first United States transcontinental railroad was born. After six years of work, the two rail networks finally joined up in Promontory Summit, Utah. To commemmorate the moment, they drove a 17.6-karat golden spike into the final tie of the railroad. 1869年5月10日是一个令人难以置信的时刻，铁路建设者们终于实现了将东海岸铁路网与西海岸铁路网连接起来的目标。在那一刻，美国第一条横贯大陆的铁路诞生了。经过六年的努力，两条铁路网最终在犹他州的普罗蒙特里峰（Promontory Summit）汇合。为了纪念这一时刻，他们将一枚17.6K的黄金道钉钉入了铁路的最后一根枕木中。

To me, the phrase “golden spike” means an incredibly difficult task joining two separate, distant systems. Here in the compiler world, it often feels like every compiler is worlds apart from every other compiler. When a language wants to call into another language, one usually has to do acrobatic rituals involving the C ABI, writing “C bindings” (wrapper functions), and sometimes making deals with various deities. 对我而言，“黄金道钉”意味着将两个独立且遥远的系统连接起来的艰巨任务。在编译器领域，感觉每个编译器之间都仿佛隔着天堑。当一种语言想要调用另一种语言时，通常必须进行涉及 C ABI 的“杂技表演”，编写“C 绑定”（包装函数），有时甚至还得向各路神灵祈祷。

And even with all that, cross-language generics don’t work (C doesn’t have generics), and things definitely won’t be memory-safe across the boundary (because C!). This is why it’s so tricky to build a language on top of Rust. And then, having memory safety and generics across the C boundary is impossible. And even if it were possible, integrating two compilers is very, very difficult. And so I thought to myself, that this sounds like a worthy goal for 2026! So here we are! 即便如此，跨语言泛型依然无法工作（C 语言没有泛型），而且跨边界的内存安全也绝对无法保证（因为那是 C！）。这就是为什么在 Rust 之上构建一门语言如此棘手的原因。此外，要在 C 边界实现内存安全和泛型是不可能的。即便可能，集成两个编译器也是极其困难的。因此我心想，这听起来是 2026 年一个值得追求的目标！所以，我们开始了！

This post is going to be about the start of my ridiculously over-ambitious endeavor to create a language with true Rust interop, with a compiler that talks to rustc seamlessly enough that we can use my Rust graphics library with cross-language generics, memory safety, linear types, Nick Smith’s group borrow checking, and a bunch of other juicy, juicy features. Tentatively, I’m calling this new language “Valen” since it’s similar (but different enough) to my existing language Vale. So read on, and this post will explain the journey so far! 这篇文章将讲述我那极其宏大且野心勃勃的尝试：创造一门具备真正 Rust 互操作性的语言。其编译器能与 rustc 无缝对接，使我们能够使用我的 Rust 图形库，并支持跨语言泛型、内存安全、线性类型、Nick Smith 的组借用检查（group borrow checking）以及许多其他令人垂涎的功能。我暂且将这门新语言称为“Valen”，因为它与我现有的语言 Vale 既相似又有所不同。请继续阅读，本文将解释到目前为止的旅程！

This entire endeavor is extremely experimental and many things have holes and sharp edges. It’s going to be a glorious few months of cleaning, rewriting, and solidifying this horror before I unleash it on the world. Feel free to check out the source code, and beware, here be dragons! 整个尝试极具实验性，许多地方还存在漏洞和缺陷。在将其公之于众之前，我将迎来几个月光荣的清理、重写和巩固这段“恐怖代码”的时光。欢迎查看源代码，但请小心，前方有龙出没！

A wish, a hope, and a dream language

一个愿望、一份希望与一门梦想语言

Rust is one of my favorite languages because of its speed, safety, and ecosystem… but there are definitely some things that would make it simpler and overall nicer for my use cases. My wish list: Rust 是我最喜欢的语言之一，因为它速度快、安全性高且生态丰富……但确实有一些改进可以让它在我的使用场景中变得更简单、更美好。我的愿望清单如下：

A borrow checker without shared-xor-mutable (一个没有“共享与可变互斥”限制的借用检查器)
Faster run-time performance (更快的运行时性能)
Resource safety via linear types (通过线性类型实现资源安全)
Zig-style comptime (Zig 风格的编译期执行)
Generational references (代际引用)
An Rc that can hold mutable data without RefCell or Cell (一个无需 RefCell 或 Cell 即可持有可变数据的 Rc)
…and a lot of other features (以及许多其他功能)

But I don’t just want a new language, because I wouldn’t have access to Rust’s ecosystem of libraries. So how do we do all that, while being able to call into Rust code? 但我不仅仅想要一门新语言，因为那样我就无法使用 Rust 的库生态系统了。那么，我们该如何在实现上述所有功能的同时，又能调用 Rust 代码呢？