VexaScript is a pet project I have been working on lately. Aiming to create a full usable modern programming language on top of TypeScript, targeting JS and C++, that is able to compile itself and to use TypeScript libraries out of the box.

https://vexa.soywiz.com/

Nowadays the tendency is to review less and less code so the programming language of choice is less relevant, and probably this is not too useful for most people, but I liked compilers, dev tools, emulators and games since I was a kid and I wanted to do this for fun and as a sandbox for learning.

For this language I wanted to cover several scenarios:

• Being able to use in the browser without relying on external servers; everything in the browser and embedable
• Be able to compile itself as a way to test a big code base, and a nice smoke test
• Be able to use TypeScript libraries out of the box with their unmodified typings
• Be able to target browser and node environments
• Be able to create desktop apps using FFI with deno and C++
• Be a non-strict superset of TypeScript with many modern features from Kotlin, Dart and other programming languages while fixing some things I don’t like
• Usable already by LLMs without wasting too many tokens

Initial development

I started developed it using mainly Codex. I decided to go with unsupervised development, trusting TDD to get it the best as possible most of the time with the limited and disperse time I had for it. I manually tried the behaviour I wanted or the fix, but without checking code most of the time. Ensured regression tests were added to avoid recurrent issues, and instructed the agents keep a journal to detect defects, do continuous improvement to the codebase and be used as resources for full blog posts. It has been a nice experience where I tried many things.

I started with small tasks using Codex in cloud mode creating PRs for each task. Then also tried Claude to expand a bit more the usage. Then finally fully developed it locally using Codex within a single branch. I alternated between big and smaller models depending on the task.

With newer models, tasks started to work better in the first try.

Journaling

Since I had little and sparse time for the project and I was a bit worried about the quality and had several regressions, in addition to add regression tests I had another idea: what if for each task make the agent keep a journal explaining what it did, which problems encountered and its general thoughts on it. Then we could later ingest those journals and identify architectural/recurrent problems. It is also like a persistent explanation of things done that we can read to understand, and we can also use it to later create proper blog posts.

Blog posts

For the VexaScript website I added a small blog with some milestones.

Even 5.6 Sol created mediocre blog posts with strange language and unaccurate claims from the journaling and instructions. So I created a skill for blog posts, and afer a few refinements it did a better work, yet it can be improved.

Skills

In addition to ingesting journaling and to write blog posts, I created several other skills.

For example: Agents are pretty bad doing destructive refactors, or finding cleaner solutions. They tend, instead, to create extra layers lo ensure keeping behaviour as before, instead of questioning whether something is really needed. And that overcomplicate things a lot where an expert developer could have find a more elegant solution to the problem reducing code, keeping it KISS and DRY and avoiding future problems. But even bigger models are bad at it. Even with explicit instructions about being KISS and DRY from my experience.

In my case, after identifying it was duplicating code (since for example the code completion or the analyser were having different results) I insisted about that by creating a destructive-negative-net-refactor SKILL to unify code.

Another SKILL I added was to add new samples to the monorepo, or deploying the website by pushing to the web branch (a separate branch to avoid breaking the website if we break something in the main branch)

Monaco and Visual Studio Code

There is a Monaco integration with Vexascript. And you can try the language directly here:

https://vexa.soywiz.com/playground

And also use Visual Studio Code:

https://marketplace.visualstudio.com/items?itemName=soywiz.vexascript-vscodeext

Codecov

Branch code coverage is over 93%: https://app.codecov.io/gh/soywiz/vexascript

C++

For C++ generation I did a small spike first to extract oilpan (the GC used in V8) in a way that could be used also using Codex: https://github.com/soywiz/oilpan-standalone

After benchmarking I ended using oilpan for GC and mimalloc for native allocations, with good results.

In fact CI has one workflow for testing the compiler is being able to compile itself in both JS and C++ code. And as for today C++ generation with -O1 is able to compile itself faster than the typescript compiler and than vexascript compiler running in node:

https://github.com/soywiz/vexascript/actions/runs/31418471930

FFI

One thing I wanted to do is to wrap SDL easily and to be able to compile it into a native executable. It works with annotations, similar to what you get in C# with [NativeLibrary]

https://github.com/soywiz/vexascript/tree/main/samples/ffi-sdl2

Preact, PixiJS, ThreeJS, Zod… samples

https://github.com/soywiz/vexascript/tree/main/samples

Standalone bundling, serving and vite

Vexascript is capable of bundling and serving with hotreloading out of the box without dependencies. For example ./vexa serve samples/pixi.

And since today there is also a vite plugin:

https://github.com/soywiz/vexascript/tree/main/samples/vite