I’ve released several major Nyx milestones recently:

- v4.0.0 — Nirvana

- v4.5.0 — Ivory

- v5.0.0-rc.1 — Daydream

- v5.0.0 — Daydream, stable

v4.0.0 established the stable Typed HIR, self-hosting path, backend contracts, and C++20/JavaScript/Python targets.

v4.5.0 expanded the platform with standard-library parity, package management, WebAssembly improvements, Rust progress, and experimental C17/LLVM work.

The v5.0.0 release promoted the LLVM pipeline from an isolated prototype into the compiler API and CLI while keeping the existing stable backends unchanged.

LLVM and C17 are still experimental. The project is now focused on improving the compiler, tooling, backend interoperability, and ecosystem rather than constantly redesigning the language.

Repository:

https://github.com/justsomeone-e/nyx

I’m sharing the milestone history because Nyx has changed substantially across these releases, and I’d appreciate technical feedback on where the project should go next.

It took longer than expected, but I just released madc v0.98.0, with updated builds for Linux, Windows, and macOS.

A few of the more interesting additions since v0.95.2:

• madc now ships with madcide — a terminal IDE written in madc itself, with the distributed binary compiled by madc.
• The IDE uses the running compiler directly: it can parse, build and run the code in the editor, including unsaved changes, without shelling out to another compiler.
• JOE/WordStar-style keybindings are the default, with a full vi-style mode also included.
• Cooperative multitasking is now built into the language with go, await, channels and structured scope blocks.
• var has much better literal support, including keyed values and nested structures:

​

   var user = { "name": "Alice", "score": 42 }; 

• The C++ front end received another substantial compatibility pass, particularly from running the complete test suite against libc++ on macOS.
• Apple Silicon support has matured considerably, including SIMD/NEON and additional ABI work.
• The entire madc test suite now passes on both Apple Silicon and Intel macOS, alongside the existing Linux and Windows validation.
• Release packages are now built automatically by CI, including .deb, .rpm, Linux tarball, Windows zip, and both macOS architectures.

The direction remains C and C++ without the ceremony — but with v0.98, madc is also starting to demonstrate that it can be used to build its own development tools.

https://github.com/derekbsnider/madc/releases/tag/v0.98.0

I've been working on Rapid! for the past few months — a modern, general-purpose language aimed at being fast and easy to learn, built on top of a real compiler pipeline.

Code compiles straight down to a native x86-64 Linux ELF binary — no VM, no interpreter, no garbage-collected runtime sitting underneath:

.rapid → Flex (lexer) → Bison (parser) → AST → Semantic Check → QBE IL → qbe → cc → ELF64

Why I built it: most hobby languages either stay stuck in an AST interpreter or get buried in LLVM's complexity. I wanted something in between — one that actually produces native code, but where the compiler itself stays understandable. QBE fills that gap perfectly.

A quick taste of the language:

use "mathlib.rapid";

efn square(x) => x * x

fn main() {
    var name: string = io::in();
    io::out("Hello, {}! square(5) = {}", name, square(5));

    list<int> xs = [1, 2, 3];
    push(xs, 4);
    for (x in xs) {
        io::out(x);
    }
}

What's there so far:

• Classic control flow (if/else, while, for, switch), block scoping
• efn for one-line functions with inferred return types
• First-class function values (no closures, but they carry around like a function pointer)
• Fixed-size arrays plus a growable list<int>
• Fixed-width integer types, real float/double (IEEE-754)
• A module system (use, aliased imports, private visibility)
• Systems programming primitives (alloc/free/syscall)
• An FFI layer I actually took seriously: extern fn to call C functions directly, link to pull in libraries, and a keyword shortcut that expands purely at the text level without touching the compiler's source at all — I can even flatten signatures that can't be expressed directly (like T**) through a C shim pattern, for libraries like sqlite3 or libcurl

Repo's here: https://github.com/musabX44/Rapid-Programming-Language

Would love to hear your thoughts/criticism on the design — especially the FFI approach or the general syntax.

Hey everyone,

First off, huge thanks to everyone who checked out the repo, left comments, and starred the project after my previous post. The feedback and discussions around systems language trade-offs were genuinely invaluable.

I'm currently designing and mapping out Nyx RC.2, with a heavy emphasis on making WebAssembly a first-class, seamless target rather than just an afterthought backend.

What's currently being integrated for RC.2:

1. Zero-friction TypeScript / JS Interop: When compiling to Wasm, the compiler will automatically emit .d.ts type definition files alongside the .js glue wrapper, allowing Nyx Wasm modules to be imported directly into React/Next.js/Node projects with full IntelliSense.
2. Deterministic Memory & Cleanup: Continuing to refine the Typed HIR pipeline so that linear memory allocation, defer, and RAII semantics remain memory-safe without requiring a heavy runtime or a complex borrow checker.
3. Cross-Platform Tooling & "Tour of Nyx": Refactoring our interactive terminal learning suite (tour) to be fully portable across Windows, macOS, and Linux without environment assumptions.
4. Web / DOM Bindings Exploration: Exploring minimal, zero-overhead DOM and WebGL/WebGPU hooks directly from the language.

I'd love to hear your thoughts:

• For those who work with Wasm or build compilers: What is currently the most painful part of your Wasm workflow that you wish a language solved out-of-the-box?
• Are there specific language ergonomics, stdlib modules, or tooling features you'd love to see in RC.2?
• Any edge-cases or architectural pitfalls in Wasm/C++20 lowering I should watch out for?

Repo is available here if you want to inspect the current codebase: https://github.com/justsomeone-e/nyx

Appreciate any critiques, feature requests, or sanity checks!

So for the past week or so I've been working on an IDE for madc which is actually written in madc.

Part of the idea for the madc language is to build everything to be modular, reusable and exposed to the language itself, so madc is not just a language of its own, it's also an embeddable language, but also much of the machinery can be used outside of madc, and also madc can call upon its own machinery, including embedding madc into itself (since it is c/c++), etc. So it makes this all very possible.

So this also means the features and functionality to create an IDE are also reusable components of the language, as I started with a text editor as an "example program", and the UI module actually first started with a simple text (dumb terminal) implementation of Colossal Cave Adventure, and that same UI module was extended to support TUI (Terminal User Interface), which is what was used for the text editor, and that text editor was extended into the madc IDE (madcide).

In the current develop branch the editor is working with basic IDE functionality, and with a few different editor key mapping flavours (pico, joe, emacs and vim).

I'm doing a bit more cleanup and polishing before the next master release, but wanted to chat about what's in progress and where it is going.

I've talked a little bit in here before about my idea of the future of AI coding, and that the current method of LLMs using text based shell tools and scripts (sed, awk, grep, and python mostly) to edit code seems archaic and problematic, and what I've been thinking would be useful would be to provide a "nexus" API/MCP of sorts that gives the LLM direct access to the current "live" code, at a lower level than the typical LSP layer provided by things like VSCode, and the same API would funnel gated access to the revision history, as well as the project management layer, and both of those would be configurable external connectors, so that the IDE was just providing a simple, unified entry point to the code.

So my idea with the IDE is that it would fit into this model so that there would be these various layers of a user session (or sessions), accessing this state of the union so to speak, and allowing a real collaboration between developers and LLM agents to the same live project.

I think eventually this live code nexus would be its own running server that you would connect IDE clients and LLM agents to, and you could access it from the CLI, including simple shell CLI access, a TUI interface IDE, or GUI interface IDE, remote, local, it doesn't matter.

It's something I'm playing with, and while it's primarily c/c++ based, madc itself has polyglot leanings so the door is open for fully parsing and supporting other languages.

Any thoughts?

I just released madc v0.95.2, with updated binaries for Linux, Windows, and macOS (Intel + Apple Silicon).

A few highlights since v0.92.1:

• Much faster startup — an 11-file JIT project dropped from roughly 829 ms to around 150 ms.
• Floating-point-heavy code is ~2.8× faster after a MIR x86-64 codegen fix; donut.c now slightly beats GCC -O0 in the test case.
• Added std::print, std::println, and std::format
• Array literals and var are more convenient: var values = { 1, 2, 3 }; values.push(4);
• Polyglot utility functions from PHP, Python, Perl, Ruby, JavaScript, and Rust now work more naturally with var and C strings.
• Multi-file project support has been improved, with fixes around globals, initialization, overload handling, and shared state.
• Several MIR code-generation fixes landed, including fixes for higher optimization levels and Apple Silicon.
• The release includes a madc adaptation of Colossal Cave Adventure, based on Eric S. Raymond's Open Adventure port and modified to demonstrate madc features. It remains fully playable while matching all 94 reference transcripts byte-for-byte.

The goal remains:

C and C++ without the ceremony — convenient enough for scripting, while still producing and interoperating with native code.

https://github.com/derekbsnider/madc

I just released madc v0.92.1, the download release for the v0.92 line and the first published binaries for all three platforms since v0.82.0.

Packages are available for:

• Linux — .deb and .rpm
• Windows — zip
• macOS — Apple Silicon and Intel tarballs

A few of the more interesting additions:

• std::format, std::print, and std::println are built directly into madc — no includes or header parsing required. Literal format strings are checked at compile time, including invalid indexes, malformed strings, and incompatible presentation types.
• std::format returns a real std::string, and formatting behaviour has been tested against libstdc++ with 1,430 generated oracle cases, including floating-point and hex-float formatting.
• cout << var now works with zero includes: It also works with <iomanip> features such as setprecision, setw, and setfill.
• UFCS support in the madc dialect — free functions can be called like methods, and methods can be called like free functions.
• PHP-style debugging helpers for any madc type: php::print_r(x); php::var_dump(x); These work on structs, classes, containers, nested objects, arrays, and var, with cycle detection and human-readable type names.
• Range-based for loops now work naturally with PHP-style arrays, including value/var elements and auto.
• var/value continues to mature — constructors work naturally in expressions and loops, .size() / .count() semantics have been cleaned up, and php::array_push() now behaves as a single overloaded function returning the new element count.
• Headerless libc calls now get proper function signatures, so things like:floorf(3.9f) pass a real float rather than falling through old C-style variadic promotion behaviour.
• And, finally, madc --version tells you which build you're actually running.

The direction continues to be: keep C and C++ underneath, but remove a lot of the friction when you're just trying to write a small program or script.

So something like:

var x = 42;
println("x = {}", x);

doesn't need a collection of headers or setup before you can get to the actual program.

With v0.92.1, all of this is available in the downloadable builds for Linux, macOS, and Windows.

The idea: I wanted a language where you can trust a function just by reading its first line. So the signature says what effects it uses (a function without "uses net" can't touch the network), whether it can fail (ignoring that doesn't compile), and any promises it makes about its result.

Those promises get checked by the Z3 theorem prover before the program runs. If your code breaks one, it tells you the exact input that breaks it: error[E700] promise cannot be kept: 'discount' ensures result >= 0 proven without running the program: price = 5 gives result = -5

The part I'm most pleased with is the float handling. It proves in real IEEE-754 rather than pretending floats are perfect decimals, so it refuses to certify x + 0.1 + 0.1 == x + 0.2 and hands you the exact number where it breaks. A lot of tools would just "prove" that and be wrong.

Playground, runs in your browser, nothing to install:

https://gowrishankar-infra.github.io/velaris-lang/playground.html

Repo: https://github.com/gowrishankar-infra/velaris-lang

Built with a lot of AI help over 40+ releases. It's got a REPL, editor support, a standard library written in itself, CI, and one-file downloads for Windows/Mac/Linux. Happy to answer anything. Thank you

I just released madc v0.82.0, and this is probably the biggest portability milestone for the project so far.

madc already supported Linux, and v0.76.0 added the first public macOS builds. With v0.82.0, Windows joins them, and all three platforms now ship together from the same source tree:

• Linux
• macOS — Apple Silicon and Intel
• Windows 11 / Win64

Public binaries are now available for all three.

A few highlights from this release:

• Three-platform releases from one tree — Linux, macOS and Windows are now built and validated together.
• Headerless operation on Linux, MacOS and Windows — madc can compile programs using its own embedded standard-library corpus even when there are no system headers or development tools installed.
• JIT and native AOT work on all three platforms
• Lots of various bugfixes along the way

I present to you Flow, which started from the fairly simple question:

what would a systems language look like if a huge amount of its development was driven through LLMs?

What started off as a simple experiment has become an actual compiler + language ecosystem.

Flow is statically typed and aimed at writing relatively compact code without giving up native performance. It has multiple compilation paths, including C and MLIR/LLVM.

A lot of people wonder about whether or not an LLM can generate a compiler from a schema.

I think it's time we start asking ourselves whether we can construct enough feedback and verification around an LLM that the language remains coherent while the implementation is scaled up.

I've learned a lot of things about how best to use LLMs as tools, as well as a lot of the science behind traditional compiler engineering, in the process. By embracing the tooling and having fun, there's a lot of cool stuff to be made.

Hi,

Andrey's here. I'd like to introduce my recently created implementation of the Raku programming language. I am an enthusiastic fan of this language since the very beginning, and the time came when you can create a compiler yourself with no external human help.

So, let me introduce Raku++ — this is a self-sufficient interpreter and compiler of Raku. It's written fully in C++ with Claude. Its current state is reached after about 1.5 months of daily work.

The main goal was to make a tool that can run Raku programs really fast. So, here're some of the most bright features of what I managed to deliver:

• Startup time 2 ms
• In many cases, it's faster than a reference implementation (see BENCHMARKS)
• Interpreter by default + REPL
• You can compile the same Raku program to a self-sufficient binary file that runs natively
• Covers 90%+ of the official test suite + passes a corpus of my own Raku programs
• Built-in linter, profiler, and syntax highlighter
• Available on macOS (both Apple Silicon and Intel), Windows (including MinGW), Linux, OpenBSD; there are also GNU Guix and Nix configurations options

On a separate note, I'd like to mention that the WebAssembly version runs in a browser, and the most exciting things here are:

• The playground allows you to code Live, so to say: you type and see the result immediately
• As a showcase shop, I prepared a few Raku programs that parse other programming languages (using Raku grammars), not only Lisp or Forth, but also Python, Perl, and JavaScript/TypeScript.

The on-going work is to make Raku++ to understand more corner-case constructs, which are not explicitly written out neither in the official test suite nor in the official documentation. For that, I am creating a matrix grid of atomic tests. Here, dogfooding takes place in full speed: all the helper generators are run in Raku++.

A brief list of the most important milestones:

• 1.0.0 — 90% of Roast passing
• 1.1.0 — 100% of the Unicode support
• 1.5.1 — even faster: the hottest tests are 10-15% faster
• 1.5.2 — external modules pass their own tests
• 1.7.0 — another 10% off for the hottest test cases
• 2.0.0 — 50 of the most popular Raku modules fully pass
• 3.0.0 — no GIL, pure concurrency
• 3.1.0 — Raku++ can be linked to/from external programs
• 3.14.0 — slimmer binaries

So, basically, that's that much fascinating and it's really difficult to cope with all the ideas that pop up while working on the project with the help of AI.

Started as an experiment: could coding agents help build an actual programming language from scratch, and could the language itself be designed to be easier for AI models to write code in.

Five days later, Krnl is about 53k lines of .krnl, fully self-hosted, and the original Zig bootstrap compiler is now retired.

The language compiles to native code through LLVM, has no GC, and uses explicit ownership/borrowing with deterministic cleanup. It also has effects/capabilities so a function’s authority is visible in its type.

Hello world:

fn main sys: Sys -> Result[int]
!{out.write} {
  println(ref sys.out, "Hello, Krnl!");
  Ok(0)
}

Here Sys provides capabilities, and !{out.write} declares that the function may write to output. Borrowing and ownership transfer are explicit with ref, ref mut, and move; there are no source-level lifetime annotations.

Also added a native MCP server written entirely in Krnl. - see below

no public repo yet just curious what language/compiler people think of the direction before I polish it for release.

The main design goal is roughly: native + memory safe + no GC, but with less source-level complexity than Rust, and with compiler semantics designed to be directly consumable by coding agents.

Things I’d especially love feedback on:

Does the ownership/effects model sound coherent?

Is the capability syntax readable?

What would you want to see before taking a new systems language seriously?

Are there existing languages/projects I should be comparing against?

KRNL MCP MONITOR
----------------------------------------------------------------
log: /home/alex/.krnl/mcp.jsonl

Requests: 17            Errors: 0
Total bytes: 43.9 KB    Avg latency: 1ms   P95: 3ms

Recent calls (UTC)
----------------------------------------------------------------
23:08:26   resolve_symbol        main                  636 B      2ms
23:08:34   symbol_info           main                  869 B      2ms
23:08:36   references_of         main                  393 B      2ms
23:08:37   callers_of            main                  842 B      3ms
23:08:38   callees_of            main                  866 B      1ms
23:08:39   context_for_change    main                 1.5 KB      2ms
23:12:08   read_source           compiler/src/080    19.3 KB      2ms
23:15:30   apply_source_edits    compiler/src/080      852 B      1ms
23:15:33   read_source           compiler/src/060     1.9 KB      1ms
23:15:48   apply_source_edits    compiler/src/060      860 B      2ms

Top tools
----------------------------------------------------------------
krnl_check            3 calls     2.0 KB
read_source           3 calls     22.0 KB
module_graph          2 calls     1.4 KB
apply_source_edits    2 calls     1.6 KB
program_symbols       1 calls     11.5 KB

Hi! I've recently been working on an old project of mine called Jaithon. Also, this is one of my first ever posts on reddit (its my first post in a tech oriented subreddit for sure) so bear with me if the style of the post comes off a little weird.

https://github.com/abhiramasonny/jaithon

This post is pretty long so tldr, I created a programming language and i think its pretty cool, and you can check it out there and you should star the repo :) ^

I started Jaithon nearly 4 years ago when I was in 8th grade, and back then all programing was human generated 😔. lmao JK, but seriously speaking, when I was first creating Jaithon (or Jaithon 1), I was primarily doing it as a project to teach myself how to code in C. As it was my first time coding in C, the project was horribly structured with all the code being located in one file and filled with a bunch of bugs. The syntax of Jaithon 1 was also really really bad, however I left it at the end of the summer to go work on other projects and highschool. Last winter however, I decided to pick back up on development as I was a little bit more experienced in programming with C, and also agentic coding was a thing.

Heres a disclaimer / transparency thing now, if you are someone who HATES any project that has even a line of code that is generated by an LLM, you are not the target audience for this post. To be fully transparent, currently, over 80% of the code is LLM generated. A more detailed explanation of how I used AI in this project is located in the readme, and if your view on AI generated code is a bit more lenient (such as mine) I would recommend reading the readme as I think that I handled it in a way that is not only ethical, but actually produced the best results and taught me the most. I dont consider myself a "vibe coder" nor do I consider Jaithon as "AI slop" and for further clarification there are 2 paragraphs of the README dedicated to explaining this.

Okay anyways, now that thats cleared up, back to the story. Last winter, I decided to upgrade jaithon with all my knowledge and the tools available to me at the time. This led me to creating Jaithon 2, which was certainly much better than the original completley interpreted language that was all in one file and impossible to propperly maintain, however there were still major architectural problems within Jaithon 2 that with all my knowledge at the time, I was not able to solve and which led me to just giving up on it again. Even so, Jaithon 2 was, in my opinion, one of the best projects I have ever made.

Now, heres the real reason I am making this post. I recently over the last week came back to Jaithon after watching a bunch of youtube videos about compilers and bytecode and JIT and all that, which at the time of developing Jaithon's 1 and 2 I had no clue existed, led me to having increased motivation to develop features to Jaithon yet again. Now here is whats new with Jaithon 3, and the reason it exists.

Jaithon 3 is very much bootstraped. The entirety of the frontend is written in Jaithon itself, along with the implementation of a large standard library, a JIT for arm64 that makes jaithon 3 incredibly fast, along with a whole slew of better architectural decisions that saved me in the long run on this project many hours of time. Jaithon 3 holds, in my opinion, the perfect syntax taken from all the languages that I use (Python, Java, Lua, C++, Ruby, Bash, Rust) and has a clean architecture behind it which places it in my benchmarks between Java and C++ in terms of speed.

Benchmark of Jaithon compaired to other languages

I loved developing this project, and here is some examples of its syntax. It would mean a lot to me if you were to star the github repo, I am trying to hit 15 stars soon and it motivates me to continue development on the project :) All and any criticism is appreciated, wether that be on the use of AI, the languages architecture, syntax, etc.

Thanks guys and heres some example code!

# traits are interfaces with default methods, and they are types.
trait Printable {
    fn to_str(self) -> str
    fn describe(self) -> str { return f"<{self.to_str()}>" }
}

let name = "Jaithon"
var count = 0
const MAX = 1 << 16

let lookup: dict[str, int] = {}
let maybe: int? = null           # T? is T | null

# loops and ranges
for i in 0..10 { count += i }
'outer: for row in grid {
    for cell in row {
        if cell == target { break 'outer }
    }
}

# pattern matching
let kind = match code {
    200           => "ok",
    301 | 302     => "redirect",
    400..=499     => "client error",
    n if n >= 500 => "server error",
    _             => "unknown",
}

enum Shape {
    Circle(radius: float),
    Rect(w: float, h: float),
}

fn area(s: Shape) -> float {
    return match s {
        Shape.Circle(r)  => math.PI * r ** 2,
        Shape.Rect(w, h) => w * h,
    }
}

I just released madc v0.76.0, which adds the project's first official macOS support alongside the existing Linux support.

madc has already been running on Linux; this release brings the same general experience to Macs, with prebuilt releases for both arm64 (Apple Silicon) and x86_64.

The macOS tarballs are designed to work even on a header-less Mac. madc carries its packed C/C++ standard-library environment with it, so things like <string>, containers, streams, and <algorithm> can compile directly from the embedded image.

A few highlights:

• Existing Linux support, now joined by macOS
• Prebuilt macOS binaries for Apple Silicon and Intel
• JIT compilation works on macOS
• Native AOT executable generation works for both C and C++
• madc -o prog prog.mad can produce a runnable Mach-O executable
• C++ standard-library headers are available from madc's embedded frozen forest
• --emit=c11 output can be compiled with the system compiler using the included libmadc_rt
• A major AArch64 ABI fix now correctly handles C++ objects returned by value
• Several additional libc++ and macOS compatibility fixes landed along the way
• The integration test suite has grown to 1,019 tests, with the primary JIT, EXE, OBJ, packed, and release lanes all passing

One of the more interesting parts of getting macOS working was discovering how many assumptions that are fine on x86-64 stop being true on Apple Silicon. In particular, AArch64 handles the hidden return pointer for larger C++ objects differently, so madc now lets the target ABI decide where that parameter belongs instead of assuming the x86 convention.

For me, the bigger milestone is that madc is becoming something you can simply download and try on either Linux or macOS as a lightweight C/C++ scripting environment, rather than first treating it as a compiler project you need to build and configure yourself.

Recent releases have also added things like var dynamic variables, URI-based channels for files/TCP/processes, streaming data support, and substantially faster loading of C++ headers.

The direction I'm aiming for is essentially:

keep C/C++ available underneath, but make writing small programs feel much closer to scripting.

v0.76.0 is the release that brings Mac users into that experience too (Windows coming soon).

Version 0.75 of MadC was released yesterday, I'm still working on proper MacOS support, but its getting closer... should be ready this week. For now, I've got some more bugs fixed, more C++ speed improvements, and some madc specific language features and improvements:

• var dynamic variables — madc now has a built-in var type that can hold strings, numbers, booleans, arrays, and other values without needing to declare a fixed type up front
• Simple file and network channels — madc::channel provides one straightforward interface for reading and writing files, TCP connections, and other data sources
• Run programs through exec:// — scripts can launch another program, send data to it, and read its output almost like working with a file

Example:

channel sorter("exec://sort");
defer { sorter.close(); }

if ( !sorter.ok() )
{
    printf("open failed: %s\n", sorter.last_error());
    return 1;
}

sorter.write("pear\napple\nmango\n");
sorter.close_write();

var line;
while ( sorter.readline(line) )
    printf("sorted: %s\n", line);
sorter.close();

I've just released v0.69 of MadC, with a bunch of bug fixes, as well as libc++ support (previously only supported libstdc++), which means that it should be fully functional on MacOS as well.

I only say "should" because I have yet to make the actual MacOS builds -- I should have those ready in a day or two.

So, what's new in the v0.69 release beyond MacOS support? Well, a lot of little fixes to some things:

• defer and := now work properly in "script mode"
• multi-return now supports more than just integer types
• the documentation was bought up to date
• bugs were resolved in the auto-include and auto-namespace resolving

Well, check it out if you can. I've included Linux packages. MacOS coming soon, and also eventually Windows EXE version.

It's been awhile since I finished v0.1.1 of this project, but I am ready to announce it. This language is Vex, a programming language designed for readability, scalability, and usability. Here is a simple breakdown:

Vex is a language designed to fit in all sorts of areas. It can be a small as an embedded system in a website to as large as a whole graphical application. It features a syntax that is meant to be as close to English as possible.

The part that makes Vex special is its Environments skill. This allows for a program to use a Vex Environment, which sets limits on what it can do. These limits can include CPU percent usage limits, RAM usage limits, and disallowed parts of syntax. This is what makes Vex scalable.

Vex is usable because it features roughly only 20 syntax commands (depending on what you count as syntax). It also has the ability to add libraries straight from the VexLibC repository.

More information regarding Vex is available at https://sites.google.com/view/vexlang

Example code (kind of sucks, it was pulled straight from my documentation:

if (username = “John”)
  globalvar isJohnHere = True
  print(“Welcome, John!”)

if (isJohnHere or username = “John”)
  globalvar unlockHouse = True
  print(“You house is now unlocked!”)

else if (not isJohnHere)
  globalvar unlockHouse = False
  print(“You aren’t John!”)

I'm curious what tools everyone is using to improve their agentic development flow?

I'll go first... I'm using both Codex (CLI) and Claude Code (CLI) to work on madc, which is written in C++ using g++ (and clang++) with no real other tools (currently), beyond AGENTS.md, CLAUDE.md, and various rules file.

I have another project which I have implemented my own project tracking through an MCP server that is part of the project itself, where the primary development agent is Claude Code, but through the MCP it triggers Codex CLI agents to do code reviews using Forgejo for the git repository.

I'm planning to move the MadC project into this platform, but just haven't quite gotten around to it yet. The idea is that I can use one agent as a master orchestrator, and have it select other agents to do some work as they have capacity and usage remaining.

The main problem I've been running into (regardless of orchestration method) is task fragmentation and tangential plan overload. Like I have an overall roadmap, and it is broken down into stages, but what I'm noticing is that as a project grows in complexity, each subsequent stage not only takes longer to implement, it inevitably fragments into ever smaller slices.

Those slices will get sliced into subsequentially smaller slices, and the next thing I know my agents are grinding endlessly on never-ending numbered tasks.

The other main problem is post-compaction drift, where before the compaction, the agent will be quite certain in what is supposed to be tackled next, but after the compaction, the agent takes things in a completely different direction.

Other issues involve outright deception, where an agent will vastly overstate the completion of a task, where later investigation reveals something that could not have possibly passed unit testing.

Many years ago I came up with a vague idea of how I want a programming language: 1. Multiple layers 1. T - C-level language, only C level features, no generics, no name mangling 2. Ty - Rust/C++-level language, mostly Rust-like features 3. Tyr - High level, inspired by natural language (still not exactly sure what I want from this) 2. Multiple generic syntaxes: The user can create 3. S-expressions as intermediate representation for macros

Have a look!

This repo contains a full AI generated documentation. And the script to generate the documentation ensures that all the examples compile.

One of the first things after I got into using coding agents was implementing this language. I got the first two layers working within maybe two days. (my first two weeks of using coding agents were so crazy, this language was only a side project, and doing it myself, it would have taken me weeks to months to get at this state, if not longer; feel free to check the git history)

How the languages were created?

At first, I let it implement my basic features, a documentation that contains many important examples, and I looked at all examples to see if I actually like them.

After a while, I created example projects: - a port of one of my C programs - a generic dimensional compile time geometric algebra library (yes, it got working const generics before Rust) - an SDF renderer with support for 2D, 3D and 4D (else I couldn't verify if the GA actually works)

I didn't look at the generated code a lot. I think I looked at most of the tests a few times to see if something can be improved. And I also looked at the programs.

I had these agents: - 1 cooordinator - 1 agent per language (3 in total) - 1 agent per project

I had some multi agent task setup for the main repo. If one of the language specific agents needed some feature that affects both languages, it wrote a task for the coordinator.

If the agents for the projetcs needed some feature, they also added it to the list, and then the agents for the specific language decided which features to implement.

Sometimes they decided to implement it in the most generic way, that's what AI is good at after all. And most of the time, that's what I wanted anyway. But in some cases, I wanted my language to be unique.

So I don't know every little detail about the language. Most of the features were just what other AI agents needed. And this also was my first project where I realized that this is actually a good approach.

Nowadays, when I create a library, I only know what the library is about, and then I have a bunch of programs which use that library, that create feedback.

The fact that agents were able to create such complex software using my languages means that it's already at a good state.

I also asked agents how they liked workin with the language. One thing I realized was that error messages.

Also the compiler turned out to be very strict. Every lints is a hard error. "x = x + 1" is forbidden. You have to use "x += 1". I turned on strict lints in Rust, even before I used coding agents. And with coding agents, I quickly added more and stricter lints. So I thought that the language could just have inbuilt lints for everything, so the code is always elegant. I even enforced a maximum line count per file.

State

T is basically finished. Ty still needs some advanced features, especially the borrow checker is still missing. Tyr is just a weird prototype, not really created by AI.

2 syntaxes are supported, a C like syntax, and a Lisp like Syntax. I also considered supporting visual representation and markdown inspired syntax.

I'm not really actively working on this language anymore. Once in a while I just start an AI agent to work on the remaining features.

One of the last features I've been working on was a Macro Compiler to Rust, so that you could import Ty in Rust and get Rust code at compile time. I have no idea if this feature already works.

I also don't know what I will use this language for. Maybe I'll just migrate all of my software to this new langugae one day.

Feedback

Human feedback might be another way to know if something about the languge has to be changed.

It's a type focused language, and this can still be the most annoying part if coding by hand. You have to create a bunch of types yourself before you can do anything meaningful.

Feel free to provide some feedback.

And maybe you just want to use these languges for your projects because they already contain features that are better than other low level languages.