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

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. 0

After six years of work, 1 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.

To me, the phrase "golden spike" means an incredibly difficult task joining two separate, distant systems. 2

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.

And even with all that, cross-language generics 3 don't work (C doesn't have generics), and things definitely won't be memory-safe across the boundary (because C!).

This is the reason no Rust++ languages exist; 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!

This post is going to be about the start of my ridiculously over-ambitious endeavor to create a true Rust++like language, with a compiler that talks to rustc seamlessly enough that we can use my Rust graphics library 4 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" 5 6 since it's similar (but different enough) to my existing language Vale.

So read on, and this post will explain the journey so far!

A wish, a hope, and a dream language

Rust is one of my favorite languages 9 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:

• A borrow checker without shared-xor-mutable
• Faster run-time performance 10
• Resource safety via linear types
• Zig-style comptime 11
• Generational references
• An Rc that can hold mutable data without RefCell or Cell
• ...and a lot of other features 12

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?

The Goal

This seemed impossible for a lot of reasons, explained in Crossing the Impossible FFI Boundary, and My Gradual Descent Into Madness.

I had forgotten that the post included this image:

Hopefully we don't have to do that! (...foreshadowing intensifies... 13)

Anyway, the more concrete, specific goal was for this program to work: 14

import rust.nobiliav.NobiliaWindow;
import rust.nobiliav.FrameInput;
import rust.nobiliav.MainLoopCallback;
... // Import constants

exported func main() int {
  w = NobiliaWindow.new(1200, 900);
  ... // set up the terrain and entities

  w.main_loop(
    // Make a Valen closure that implements the Rust `trait MainLoopCallback`
    &MainLoopCallback((win, input) => {
      key = input.key();
      if (key == key_arrow_left()) {
        win.rotate_camera(-4, 0);
      } else if (key == key_arrow_right()) {
        win.rotate_camera(4, 0);
      } else if (key == key_arrow_up()) {
        win.rotate_camera(0, 4);
      } else if (key == key_arrow_down()) {
        win.rotate_camera(0, -4);
      }
    }));
  
  return 0;
}

Of course, this required answering a lot of very hard questions.

I'll ask them in the code:

// How do we know what things are importable from Rust?
import rust.nobiliav.NobiliaWindow;
import rust.nobiliav.FrameInput;
import rust.nobiliav.MainLoopCallback;
...
exported func main() int {
  // How do we know what static methods exist in a Rust type?
  // How does Valen know what parameters rustc expects here?
  w = NobiliaWindow.new(1200, 900);
  ...
  w.main_loop(
    // How do we make a Valen closure implement a Rust trait?
    // How do we know the methods on a Rust trait?
    &MainLoopCallback(
      // How will Rust call BACK into Valen code? Monomorphizer integration?
      // Can the optimizer inline a Valen function into a Rust function and vice versa?
      (win, input) => {
        key = input.key();
        if (key == key_arrow_left()) {
          win.rotate_camera(-4, 0);
        } else if (key == key_arrow_right()) {
          win.rotate_camera(4, 0);
        } else if (key == key_arrow_up()) {
          win.rotate_camera(0, 4);
        } else if (key == key_arrow_down()) {
          win.rotate_camera(0, -4);
        }
      }
    )
  );
  return 0;
}

However, these questions hide the real, central question underneath it all.

The central question

As many of you know, the most common way for other languages to call into Rust is if the Rust library exposes its functions as extern "C", and exposes its types as repr(C).

This is because C is the de-facto universal translator between low-level languages.

It's also because Rust doesn't have a stable ABI yet. 15

"What's an ABI?" you might ask.

To simplify a bit, an "ABI" is basically how Rust answers these questions:

• "If the user calls a function, passing a struct by value, do we compile it to pass-by-reference, or do we pass it in a register?"
• "If the user specifies a bool, then a u64 integer, then a bool, do we put those two bools next to each other to save space?" 16

Alas, Rust hasn't yet committed to an ABI.

So, using the C ABI (with extern "C" and repr(C)) is the only option for other languages to call into Rust.

But C doesn't have generics. There's no such thing as void do_something<T>(T* thing) in C.

This means that other languages can't call into generic Rust functions.

This is a problem for us, because... well, recall this main_loop call from above:

exported func main() int {
  ...
  w.main_loop(&MainLoopCallback((win, input) => { ... }));
  ...
}

Here's what Rust's main_loop actually is:

impl NobiliaWindow {
  pub fn main_loop<C: MainLoopCallback>(&mut self, cb: &mut C) {
    ...
  }
  ...
}

That's right, that parameter right there is generic, taking anything that implements trait MainLoopCallback.

But the C ABI has no generics! But we need generics. Blast! We're stuck.

So the central question, the central mystery to solve, is how do we do cross-language generics?

Cross-language generics

There are actually two levels to this question:

1. How do we call into a Rust generic function?
2. How do we call into a Rust generic function that calls back into Valen? 17

Here's a simpler example to illustrate the first level:

import rust.std.vec.Vec;

exported func main() int {
  my_vec = Vec<int>();
  my_vec.push(21);
  my_vec.push(42);
  // Returns 42
  return my_vec.pop().unwrap();
}

When we say my_vec.push(21), we're calling the generic function Vec<T>::push.

Luckily, in the Madness post, I managed to get it working for C:

// Import a rust type directly (no bindings!)
#pragma rsuse VecInt = std::vec::Vec<u64>
// Must specify each method you want to use
#pragma rsfn VecInt_with_capacity = VecInt::with_capacity
#pragma rsfn VecInt_capacity = VecInt::capacity
#pragma rsfn VecInt_drop = VecInt::drop
// Plus the magic incantation, and...
#include "rust_deps/rust_deps.h"

#include <stdio.h>

int main() {
  // ...presto, we can use rust libraries!
  VecInt argv = VecInt_with_capacity(42);
  printf("Capacity: %lu\n", VecInt_capacity(&argv));
  VecInt_drop(argv);
  return 0;
}

Capacity: 42

I called this my "most cursed exploration" because of the acrobatics it had to do:

• It ran rustdoc (yes, the documentation generator!) and parsed its json output with the rustdoc_types library, to figure out what types were usable, and what impls had what methods.
• It ran rustc with a "scouting program" that literally just prints sizes; println!("{}", size_of::<Vec::<u64>>()) prints 24 bytes. (Thanks to matklad and literallyvoid for helping me improve this part!)
• It then ran rustc again with a "instantiation program" which generated a "wrapper C library" that the C program could statically link to.
• Vale's memory safety approach didn't really line up with Rust's, so a user had to stick to certain patterns.

And it had some limitations:

• We need to fully spell out the generic args, like VecInt = std::vec::Vec<u64>.
• We need to import every method we use, in a #pragma rsfn.

But the hardest limitation is that we can't make a C type implement a Rust trait.

That means you can't use HashMap::get, because its k key must implement the Hash and Eq traits.

Still, as cursed as it was, the 2024 solution was actually a pretty good start.

Above, I said that there are two levels to the cross-language generics question:

1. How do we call into a Rust generic function?
2. How do we call into a Rust generic function that calls back into Valen?

The 2024 solution solved most of #1 in spirit, even though it got information from Rust in an odd way.

And it hinted that there might be an answer to #2, if a language was designed with it in mind and Did Things Properly™.

Interop, Done Properly

Of course, there's no such thing as "doing things properly", because everything I'm about to say is very unsupported by the Rust compiler.

But I felt like the next step in the endeavor would be to talk to rustc directly, 18 instead of invoking it (twice!) from the outside. 19

And it turns out, one can actually run the rust compiler as a library, using rustc_driver's run_compiler function!

use rustc_driver::{Callbacks, Compilation};
...
fn main() {
  ...
  let callbacks = ValenRustInteropCallbacks { ... };
  ...
  rustc_driver::run_compiler(&rustc_args, &mut callbacks);

The two arguments to run_compiler influence what rustc does.

• rustc_args tells rustc what Rust libraries we want to use, so it loads and compiles them, so the Valen typing pass can ask questions about them. 20
• callbacks specifies observers that tell us when rustc has loaded and compiled all of its dependencies. 21 Then, the Valen typing pass can ask rustc questions about the Rust crates it depends on, and generate Rust MIR functions from our Valen code.

However, there was a problem with that: Valen couldn't lower to Rust's MIR, because it didnt't have the capabilities Valen needed:

• MIR's mutable references are unique, which means it can't do our Group Borrowing memory safety approach, which allows shared mutable references.
• MIR doesn't let us specify LLVM's alias groups / !alias.scope on load/store instructions, which is something that makes group borrowing faster.
• MIR can't express comptime metaprogramming, which is on my dream language wish list.

Rust's MIR was designed for Rust. So it's a great target for Rust code, not Valen code... alas.

Of course, if Valen used its own IR and backend instead of Rust's, that would mean that the compilers would need to work with each other in a very interesting dance.

The dance

"The dance" is how rustc's monomorphizer and valenc's monomorphizer need to work together to fully discover all of the functions that they are calling in each other.

A "monomorphizer" is what turns a generic function foo<T> into its substituted functions foo<i32>, foo<bool>, foo<String> etc. depending on what types one calls foo<T> with. 22

To illustrate, here's an example program showing Valen calling Rust calling Valen:

exported func main() {
  vs = MyStruct();
  rust_func<MyStruct>(&vs);
}

struct MyStruct { }
impl RustTrait for MyStruct {
  func method<N int>(self: &MyStruct) {
    print("hello from valen! " + N);
  }
}

trait RustTrait {
  fn method<const N: i32>(&self);
}

fn rust_func<T: RustTrait>(x: &T) {
  x.method::<4>();
  x.method::<6>();
}

For a second, let's pretend that main, rust_func, and method were all Rust functions.

If that were the case, rustc would do this:

(For readability, I'll shorten "monomorphizer" and "monomorphize" to "mono")

• rustc starts mono'ing main.
  • rustc sees rust_func<MyStruct>, wants it to be mono'd.
    • rustc starts mono'ing rust_func<MyStruct>.
      • rustc sees x.method::<4>, wants it to be mono'd.
        • rustc monos MyStruct::method::<4>.
      • rustc sees x.method::<6>, wants it to be mono'd.
        • rustc monos MyStruct::method::<6>.

And that would have been easy; a simple task for rustc.

However, main and method are Valen functions.

So it's more like this, where rustc and valenc need to talk to each other:

(Only difference below: four "rustc"s become "valenc"s)

• valenc starts mono'ing main.
  • valenc sees rust_func<MyStruct>, wants it to be mono'd.
    • rustc starts mono'ing rust_func<MyStruct>.
      • rustc sees x.method::<4>, wants it to be mono'd.
        • valenc monos MyStruct.method<4>.
      • rustc sees x.method::<6>, wants it to be mono'd.
        • valenc monos MyStruct.method<6>.

In other words, we need to make rustc's monomorphizer and valenc's monomorphizer able to call each other.

So our design needs to enable that. 23

The current design

The current design works like this:

• (Like before) rustc_args tells rustc what Rust libraries we want to use, so it loads and compiles them, so the Valen typing pass can ask questions about them.
• callbacks specifies observers that tell us:
• When rustc has loaded and compiled all of its dependencies, so the Valen typing pass can ask rustc questions about the Rust crates it depends on, and generate empty Rust functions corresponding to the Valen exported functions (such as main).
• When rustc is monomorphizing one of those empty Rust MIR functions, we can intercept that call, make Valen monomorphize it instead, and also tell rustc what other Rust functions this Valen function calls (so rustc can monomorphize those too).
• When rustc is about to ask the rustc LLVM backend to lower this (empty) function to LLVM, we intercept that, have Valen's LLVM backend lower it to LLVM instead.

Of course, those last two capabilities definitely don't exist in rustc.

So, I did the nuclear option. I patched the Rust compiler to add those last two callbacks.

Honestly, this was the riskiest part of the whole endeavor. The patches are small (~100 lines), but one of them is basically a hack that assumes rustc is using LLVM, which of course isn't always true. 24 It works, but it's definitely not upstreamable.

Luckily, I already have a better approach in mind for the next iteration...

Of course, that's just the rustc side of this. I then had to rearchitect the Valen compiler to actually use these capabilities. That took most of 2026, and was a massive endeavor that will definitely get its own post (stay tuned!).

The Golden Spike, but even more Golden

I have a little game engine I've been experimenting with, to try and figure out new ways to do screen-space refraction, like this: 25

I thought, this would be a perfect goal to set. This would be Valen's first contact with Rust, like the golden spike that completed the first transcontinental railroad across the US.

If I could get it working, then I could finally start developing the game that I've been trying to start on since the dawn of time.

My first goal was actually something like this, where main owns the while loop:

import rust.nobiliav.NobiliaWindow;
import rust.nobiliav.FrameInput;
import rust.nobiliav.MainLoopCallback;
...
exported func main() int {
  w = NobiliaWindow.new(1200, 900);
  ...
  while w.running() {
    input = w.tick();
    key = input.key();
    if (key == key_arrow_left()) {
      w.rotate_camera(-4, 0);
    } else if (key == key_arrow_right()) {
      w.rotate_camera(4, 0);
    } else if (key == key_arrow_up()) {
      w.rotate_camera(0, 4);
    } else if (key == key_arrow_down()) {
      w.rotate_camera(0, -4);
    }
  }
  return 0;
}

but apparently wgpu (and apps in general nowadays?!) don't let us own our own event loop. I remember the good ol' days when you could just GetMessage(&msg, ...) or EvtGetEvent(&event, ...) in a while(true) and everyone was happy.

I was faced with a choice: do something less awesome, or expand the scope of my golden spike to include Rust calling back into Valen.

You all know me. You know what I chose!

I decided to implement something like a closure:

import rust.nobiliav.NobiliaWindow;
import rust.nobiliav.FrameInput;
import rust.nobiliav.MainLoopCallback;
...
exported func main() int {
  w = NobiliaWindow.new(1200, 900);
  ...
  w.main_loop(&MainLoopCallback((win, input) => {
    key = input.key();
    if (key == key_arrow_left()) {
      win.rotate_camera(-4, 0);
    } else if (key == key_arrow_right()) {
      win.rotate_camera(4, 0);
    } else if (key == key_arrow_up()) {
      win.rotate_camera(0, 4);
    } else if (key == key_arrow_down()) {
      win.rotate_camera(0, -4);
    }
  }));
  return 0;
}

After a lot of work (that led to discovering the dance and the current design), it finally all connected!

At last, I got my first render: 26

And with that first render, the golden spike was hammered into place, and the transcontinental compiler was born.

Over half a year of work, theorizing, planning, hacking, refactoring, and rearchitecting had finally come to fruition.

Of course, we aren't done yet!

We don't just want Rust interop, we want memory-safe Rust interop!

Memory safety across the boundary

Like I said above, I'm designing a memory safety approach that builds on Group Borrowing, which is a more flexible form of borrow checking that allows for shared mutable references.

If my guess is right, a well-designed blend could have even more benefits than we talked about in that article:

• We could have a mutable reference into an otherwise-immutable object
• Rc could hold mutable objects without RefCell or Cell (something I call "the holy grail", long story!)
• In some cases, it could even be faster at run-time 27

With careful enough language design, group borrowing can actually be a superset of Rust's borrow checking, making it so we can borrow-check over the boundary.

This post is long so I'll save the details for the next one, but TL;DR: it's not complete yet, but this prototype is doing some borrow checking over the boundary!

Resurrecting Vale(n)

Vale is my greatest achievement, my own personal crown jewel of memory safety design. It was a blend of generational references and region borrowing, both of which had never been seen before. It directly inspired Mojo to add linear types, even before I worked for them.

Vale was also pretty unique in that it was a "high-level high-performance" language (as opposed to a lower-level "systems programming" language). This let it be much more strict about memory safety, which allowed for a lot of interesting features like Perfect Replayability.

This new language is a different beast altogether.

• It uses group borrowing (purely compile-time memory safety) instead of generational references + region borrowing.
• It's a systems programming language, which means even more freedom and speed (via group borrowing), though it wouldn't be as safe (because it'll have unsafe like Rust).

It's so different, that it truly deserves its own name. 28

And thus, Valen is born!

That's all for now!

These are ideas I've been itching to try for years, and they're finally all coming together into something beautiful. 29

This post represents my work for most of a year, and I had to keep it from exploding into a 40-page tome like some of my other posts, so I'll wrap things up here.

This is just the tip of the iceberg, so stay tuned by subscribing to my RSS feed, r/valen, or joining the Valen discord.

Cheers!

- Evan Ovadia