What's New in NXD

The compiler front end was rewritten in Rust

One of the largest changes was rewriting NXD's entire compiler front end in Rust.

This wasn't simply a change in implementation language. It gave NXD a stronger foundation for continuing to develop its parser, semantic analysis, diagnostics, and intermediate representation while maintaining clearer boundaries between the different stages of compilation.

That distinction is especially important as NXD continues toward its goal of supporting multiple backends. NXD's language semantics should be defined by NXD itself, rather than by the limitations or behavior of any one target language.

Exploring asynchronous NXD

October also included significant exploration into how asynchronous and concurrent programming should work within NXD.

Rather than simply adopting the behavior of one of NXD's target languages, this work focused on determining what concepts such as tasks, synchronization, and channels should mean at the NXD language level.

This also led to early runtime work needed to support those semantics consistently as NXD's backend support expands.

Better diagnostics for literals

NXD's diagnostic system also became considerably more precise.

Literal handling received additional validation and dedicated diagnostics, allowing the compiler to identify specific problems earlier and provide more useful information about what went wrong and where.

For someone writing NXD, the goal is simple: when the compiler rejects something, the error should help explain the problem instead of merely announcing that compilation failed.

A much larger test corpus

Testing expanded substantially alongside the compiler changes.

The primary Nim test corpus grew from 110 to 156 tests.

Current overall pass rate: 127 of 156 tests correctly passing or failing as expected (81.40%).

An additional 312 tests were introduced in preparation for the future .d and .ex backends.

Those future-backend tests are particularly useful because NXD is being designed around its own language semantics. As additional backends mature, the same NXD behavior can be tested across them rather than developing a different interpretation of the language for each target.

Continuing the pace into November

November has already started with another structural change: the NXD VS Code extension now has its own repository.

Previously, the compiler and editor tooling lived much closer together. Separating the extension gives the editor integration its own development and release lifecycle while allowing the nxd_language repository to remain focused on the language and compiler itself.

The newly separated extension has now been packaged as a VSIX, published, and tested against the main NXD compiler repository. Parser and validation functionality have also been exercised after the move, including valid programs producing clean diagnostics and intentionally invalid programs continuing to report errors.

In other words, the repositories may now be separate, but the development experience remains connected.

What's next?

With the extension migration complete, attention can return to expanding NXD itself. The roadmap is also being reevaluated as the language has evolved faster and somewhat differently than originally anticipated, with some requirements arriving earlier and new areas of work emerging along the way.