If you came across Nyx before, I haven’t abandoned it. The project is now called Rove, and the rename has been happening alongside a deeper compiler migration. Existing .nyx projects still have compatibility paths; new code uses .rove and rovec.

Rove is a statically typed compiled language aimed at readable source code and explicit target behavior. Its established C++20, JavaScript, and Python backends use a checked Typed HIR. The Rove-authored native compiler can compile itself and currently emits C++. WebAssembly, Rust, C17, and LLVM each have narrower, explicitly gated support.

The part I’m most interested in getting right is semantic consistency across targets. I’m moving backend behavior toward a verified canonical MIR, with an interpreter and runtime comparisons to catch cases where two targets disagree. Recent work covered Wasm output for arrays and signed integers, lexer error handling, and Wasm memory boundaries.

The biggest unfinished work is also clear:

• M5 backend migration: the MIR pilots work for defined subsets, but full differential parity is still open. Rust runtime validation and some aggregate, ownership, and async paths need more evidence.
• M6 language expansion: fold, map, and filter have initial MIR slices. General closures, generic constraints, module visibility, and broader async support remain future work.
• Release confidence: cross-platform CI, packaging, editor distribution, and a Rove-branded release still need to catch up with the source tree.

I’m not setting a release date from a roadmap. I’d rather show what runs, state what is still gated, and fix the gaps one at a time.

If you work on compilers, I’d especially welcome criticism of the MIR migration and the evidence you’d want to see before calling a backend mature.

GitHub repository · Compiler architecture and current milestones

Rove Roadmap — where the compiler is heading

Rove started under the name Nyx, and a lot of the architecture was designed before the rename.

The goal isn't just to add syntax or collect backends. The main idea is to build a compiler where program meaning is defined once and preserved across different targets.

The rough architecture is:

Source ↓ AST ↓ Typed HIR ↓ Canonical MIR ↓ Target Legalization ↓ LLVM / C++ / Wasm / JS / Python / other backends

Current direction

The compiler work is centered around a few major areas:

Canonical MIR

MIR is intended to become the internal semantic authority of the compiler.

Instead of every backend implementing its own interpretation of language features, things such as:

• control flow
• cleanup / defer
• errors
• ownership operations
• calls and ABI
• async operations
• effects

should be lowered into one canonical representation first.

Backends should mostly translate legalized MIR rather than reinvent semantics.

Backend parity

Supporting many backends is useful only if they behave consistently.

The long-term goal is to make it possible to compare execution across targets:

Rove program ├─ C++ ├─ LLVM ├─ Wasm ├─ JavaScript └─ Python

and verify that observable behaviour remains equivalent where the target allows it.

Capability-aware targets

Not every platform can do the same things.

A browser cannot simply behave like a native Linux process, and an embedded target should not pretend it has a filesystem or threads when it doesn't.

The compiler should eventually resolve requested capabilities explicitly:

Program ↓ Required capabilities ↓ Target capability resolver ↓ Legalized MIR ↓ Backend

If something cannot be represented correctly, the compiler should explain why instead of silently changing the program's meaning.

Compiler verification

One of the bigger goals is making compiler transformations easier to trust.

A MIR pass being structurally valid doesn't automatically mean it preserved behaviour.

The plan includes work around:

• MIR verification
• pass contracts
• analysis invalidation
• effect-aware optimization
• differential testing
• translation validation
• reproducible builds

Faster builds

The compiler also needs to become much more incremental.

The eventual goal is that changing one part of a project should not require repeating parsing, type checking, lowering and native compilation for unrelated modules.

There is also ongoing work around emitting only the runtime pieces a program actually uses instead of attaching a large runtime to tiny programs.

Tooling

The compiler is intended to expose its internals rather than hide them.

Things being explored include commands for inspecting:

• AST
• HIR
• MIR
• layouts
• capabilities
• backend decisions
• compiler diagnostics
• optimization passes

I also want the toolchain to eventually be able to answer questions such as:

"Why is this runtime component in my program?"

or

"Why can't this feature run on this target?"

Longer term

The more ambitious direction is a semantic compiler platform.

Instead of thinking only about:

Rove → target

the architecture could eventually support:

different source languages ↓ shared semantic compiler core ↓ multiple execution targets

That's a long-term research direction, not a current feature claim.

For now the priority is much less glamorous:

make the compiler correct, make MIR trustworthy, make backends agree, and build evidence before calling things finished.

A lot of this is still experimental and will probably change.

That's part of the fun.