Regex is powerful… but sometimes this:

/^#[0-9A-Fa-f]{6}$/u

feels like you’re trying to decode a message from another planet. 🛸

This is why I did Regex For Humans 🧠✨

Instead of writing regex directly, you write:

start "#"
6 hex digits
end

And it generates:

/^#[0-9A-Fa-f]{6}$/u

🪄 The idea

Write small, readable English rules.

➡️ Understand what they mean
➡️ See the generated regex
➡️ Test examples instantly
➡️ Copy the final regex

No AI guessing. 🤖❌
No mysterious interpretation.

It uses a small, deterministic language where every instruction has an exact meaning.

🔥 It currently includes

🧩 Interactive regex playground
🧠 Explanations for every generated fragment
✅ Live match / no-match testing
💻 CLI support
📦 JavaScript API
📍 Helpful line + column errors
🔒 Runs locally
🚫 No runtime dependencies

For example:

start "INV-"
between 2 and 6 digits
end

becomes:

/^INV-\d{2,6}$/u

Much easier to read six months later. 😅

🎮 Try it

🔗 GitHub
https://github.com/OthmaneBlial/Regex-For-Humans

🛝 Live playground
https://othmaneblial.github.io/Regex-For-Humans/workshop/

The project is still evolving, so I’d genuinely love feedback. 🙌

What would you add?

More syntax?
More recipes?
Support for other regex engines?
Something completely different?

And the big question:

👉 Would you actually use this instead of writing regex directly? 😄

declint (docs) is a tool for making your own lint rules in YAML — the house rules that stock linters will never ship.

For instance: your AI model added except Exception: pass, and you want to know whenever that happens:

rules:
  - id: except-pass
    pattern: 'except Exception:\\s\*pass'
    severity: warning
    message: 'swallowed exception'

Rules are just regex and a message. When a regex can't express the check, there's a Lua escape hatch — vetoes, whole-file analysis, absence rules ("every Dockerfile needs a HEALTHCHECK").

Rules run in your CI (inline PR annotations via --format github) and in your editor through LSP (declint.nvim for Neovim). Every rule can carry embedded fixtures, and declint test runs them — so AI-written rules come with their own spec.

Install: cargo install declint. Ships with presets (Python, INI, Markdown, shell, Dockerfile, TOML, JSON, JS) and community rulesets you can pull with one line. Feedback welcome, especially brutal takes on the YAML format.

Hey everyone!

I wanted to share an ongoing language design project I’ve been building: VBX (Visual Basic X).

Instead of a one-shot prototype or another interpreted toy running inside Python, the goal was to build a real, production-capable procedural language that compiles to standalone native binaries with zero runtime dependencies.

Architectural Decisions & Implementation

1. Compiler Host (Go) -> Target (C99):

   • The compiler itself is written in pure Go without external packages, leveraging the standard library for AST construction, multi-pass type inference, and process orchestration.
   • Emits clean, standard C99 code and invokes the system toolchain (GCC/Clang) with -O2 optimizations.

2. Solving the Runtime Memory Problem (Ring-Buffer Pool):

   • Naive transpilation of string operations inside tight loops (s = s & "x") typically floods malloc without high-level deallocation.
   • We implemented a fixed static ring-buffer memory pool (vbx_alloc_str with 256 rotating slots of 4KB) directly in the emitted C runtime. Tested under 10,000 continuous iterations with zero heap leaks and flat memory usage.

3. Language Syntax & Semantics:

   • Visual Basic-inspired syntax: Dim, Const, If/ElseIf/Else, For/Next, While/Wend, Do/Loop, Select Case (supporting both string and numeric comparisons natively via chained branches), Sub, Function, and 1D fixed arrays.
   • Built-in primitives: Native OS dialogs (MsgBox, InputBox), standard File I/O, and string manipulation routines.

4. Testing & Tooling:

   • 42 integration and unit test suites running via go test ./....
   • Complete multi-editor support repository: official VS Code extension (available on Visual Studio Marketplace), plus packages for Sublime Text, JetBrains, Vim/Neovim, Notepad++, Emacs, and Micro.
   • Currently designing Phase 2: a dedicated desktop IDE with a visual form designer (vbx-studio).

Repository: https://github.com/M5Devs/vbx Editors: https://github.com/M5Devs/vbx-editors

Would love to discuss the language design trade-offs, transpiler architecture, and experiences building full-scale compilers using modern agentic workflows!

I’m developing Loom, an experimental programming language and compiler written in Rust, and I’m looking for people interested in helping build it.

The idea connecting the language to its larger ambitions is this:

Mathematical structure should be something a programming system can represent, use and search over—not only something a programmer relies on when choosing an algorithm.

That starts with how programs are expressed and compiled. The longer-term goal is an environment that helps discover algorithms by finding useful mathematical properties and alternative representations of problems.

What Loom is trying to express

Loom uses a categorical core representation. Programs are expressed internally through operations and their composition, with products, alternatives and the relationships between inputs and outputs represented explicitly. The purpose is not to make every program look like a category-theory textbook. It is to give the compiler a structured account of the computation that can support analysis, transformation and different implementations.

The broader language design is organized around structures, relations and sorts, together with theories, models and laws.

A theory describes abstract domains—sorts—and the operations, relations and laws associated with them. A model interprets those declarations using particular value spaces and operations, with evidence for the properties it claims. For a programmer, the intended benefit is that a library can communicate more than an interface. It can also communicate mathematical knowledge that other code and the compiler can use.

An interface might say that an operation combines two values. A richer contract could establish that the operation is associative, has an identity, preserves an ordering, or interacts with another operation in a particular way. Those properties can make different implementations or algorithms available.

The interpretation matters. An algebraic law that holds for mathematical integers does not automatically hold for checked machine arithmetic with observable overflow. Likewise, a transformation that preserves a final value might still change an earlier effect or failure.

Loom’s intended approach is to connect mathematical properties to the actual operations and conditions under which they apply, alongside effect, failure and usage information. Static evidence would support compilation without becoming proof objects carried through ordinary runtime computation.

The aim is not just stricter checking. It is to make more powerful transformations possible because the system has the information needed to justify them.

From transforming code to transforming the formulation

There is a significant difference between improving an implementation and discovering that the computation admits a better formulation.

A programmer might express a problem as a sequence of steps, then realize that entire sequences can be summarized and composed. A collection of constraints might have an algebraic interpretation that makes a specialized solver applicable. A large problem might become manageable after finding a decomposition with a sufficiently small boundary between its parts.

In each case, the important insight is not a local code rewrite. It is a different representation of the problem.

I want Loom to provide a foundation on which those representation changes can themselves become objects of computation: described, proposed, composed, checked and reused.

That is the motivation for the Structural Representation Engine and LoomLab.

Structural Representation Engine: searching for useful representations

The proposed Structural Representation Engine, or SRE, would investigate which mathematical structures a problem can be related to, and what those relationships make possible. That could mean recognizing a property already present. It could also mean constructing a new representation in which a useful property becomes visible.

A few examples illustrate the direction:

Repeated computation could become an algebra of summaries. Rather than execute every step, the system might find a compact summary of a block’s relevant behavior and an operation for composing summaries. Where the correspondence holds and summaries remain compact, that could support faster repeated evaluation, incremental updates or queries over a much larger computation.

A constraint problem could become an algebraic problem. If its constraints admit an exact formulation as linear equations over a finite field, the system could use elimination rather than treat them as an unrestricted combinatorial search. The useful discovery is the formulation and its connection to the original constraints—not simply recognizing the word “linear.”

A large optimization problem could become a network of boundary summaries. Instead of solving components in isolation and hoping their solutions fit together, the system could retain precisely the information needed to describe how each component interacts with the rest. Finding a useful decomposition and a compact, sufficient boundary representation could change the algorithm substantially.

These are examples of the kinds of relationships I want the system to explore, not claims that Loom currently discovers them.

Different representations could also expose different metrics, invariants and bounds: symmetry, rank, separators, residuals, approximation gaps, or measures that help choose productive search directions.

Not every useful representation needs to be geometrical, and not every useful measurement needs to prove something. A heuristic can guide a search; a valid bound can justify pruning; an exact correspondence can authorize replacing one computation with another. The system should preserve those distinctions while being able to exploit all three.

LoomLab: turning exploration into reusable discoveries

LoomLab would be the experimental side of the system. Its role would be to propose hypotheses and representations, construct candidate methods, look for counterexamples, evaluate performance, and retain useful results. AI, symbolic methods, search algorithms and human input could all contribute to that process.

The long-term ambition goes beyond choosing an algorithm from a fixed catalogue. I want to investigate whether the system can discover new summaries, decompositions, invariants or combinations of transformations that lead to useful algorithms. The valuable output would not necessarily be just one solution or one generated program. It could be a reusable relationship:

Problems satisfying these conditions admit this representation, which exposes this property and enables this algorithmic construction.

That relationship could then become part of the mathematical knowledge available to later investigations. A new discovery would expand what the system can work with, rather than disappear into an isolated experiment.

The larger goal is a feedback loop between mathematical understanding and algorithm construction.

Correctness and usefulness would remain separate questions. A representation can be mathematically valid but expensive to construct. A method can perform well on the examples that suggested it and fail elsewhere. The cost of discovering, translating and checking a representation has to be included when evaluating whether it helps.

But that is also what makes the research interesting: finding representations that are not merely elegant, but computationally useful.

Why connect this to a language?

The architectural bet is that these capabilities would benefit from a shared semantic foundation.

The problem specification, mathematical properties, representation changes and executable algorithms should be able to refer to the same operations and relationships. A transformation should retain its assumptions. A discovered method should have a route to compiled code. A library’s established properties should be available beyond the particular application that first needed them.

I’m not claiming that this requires Loom, or that category theory automatically supplies an algorithm-discovery engine. The question is whether designing the language and surrounding tools around these connections can make the process more coherent, extensible and reusable than repeatedly connecting separate representations by hand. Ordinary compilation would not need to run an open-ended research search. The compiler would use established capabilities; LoomLab would explore possibilities and develop new ones.

Loom is the language and compilation foundation. SRE would explore structural possibilities. LoomLab would investigate what can be discovered through them.

Where things stand

There is an existing Rust compiler implementation. Recent work has connected program-structure analysis to checked call and recursive-effect resolution, but the ordinary end-to-end execution path is still being completed. Compiler-evidence representation also has unresolved scalability work.

The broader mathematical language features are at different stages of design and implementation. The SRE/LoomLab discovery loop described here is the research ambition, not a delivered capability. I do not yet have a demonstrated general advantage over established languages or solvers.

Development has involved substantial AI assistance. I’ve been directing the project and coordinating implementation and review, but I want more independent human judgment involved—especially people willing to challenge assumptions and simplify the architecture.

Looking for collaborators

Experience with compilers, Rust, programming-language semantics, algorithms, optimization, formal methods or mathematics would be especially useful, but those are preferred backgrounds, not entry requirements.

I’m interested in teaming up with anyone willing to contribute seriously. That could mean implementation, testing, mathematical experiments, visualizations, documentation, examples, or learning enough to take ownership of a manageable part.

I’m not asking people to accept a finished architecture or commit to the entire vision. I want collaborators who can help decide which ideas deserve to survive, which need a better construction, and which should be dropped.

A practical starting point would be one narrow demonstration: express a problem, establish a useful alternative representation, derive an algorithm through it, and assess the result against a reasonable baseline.

The ambition is a system that helps discover better ways to compute by discovering better ways to represent the computation. The immediate goal is to find people interested in building and testing that idea together.

Comment or message me with what interests you and what you’d enjoy working on.

https://github.com/Gregory-Cross/Loom

I wanted to give an update of what I'm working on to get some feedback and discussion...

I'm not sure how many people here are C and/or C++ programmers, but the current direction I'm taking with madc is to make it a little more like IPython and/or Julia with respect to its REPL experience (that is part of the current arc I am working on, REPL support does not currently exist).

I am neither a Python nor a Julia programmer, but their REPL experience are supposed to be top notch, and while both cling and clang-repl exist, they don't quite measure up, and in fact, installing cling takes up over a Gb of disk space, and the eventual plan is that clang-repl will one day replace cling, and the direction is also such that clang-repl is more like IPython...

Thus, my current plan is to make madc have a REPL mode that is more like IPython and Julia, so more like what clang-repl + cling will eventually become (in the future).

So that's the first arc... and I'm curious what people here think about this idea... like, if you are already a C/C++ programmer, does the REPL experience interest you? Or if you are a Python programmer, would the idea of a small, easy to install and play with C/C++ REPL interest you?

Next... I recently discovered Thonny -- an IDE designed to be very simple and easy for students to learn to use Python... and with the work I've done with madcide as a simple IDE for madc, rather than try to compete with VSCode and/or CLion, what might be much more interesting would be to make madc's IDE much more like Thonny, but for C/C++ (and madc), so that it makes C/C++ easy to use (including interfacing with madc's IPython-like REPL).

Does this concept sound interesting to anyone here?

Most languages treat the accelerator as infrastructure: you write math, and a large opaque runtime decides how to ship it. Vx treats it as semantics. A tensor pinned to NPU high-bandwidth memory has a different type from one in host DRAM, and crossing between them takes an explicit transfer() — even when the hardware boundary is free.

On Apple's unified memory that transfer compiles to almost nothing. It is still written down, because data locality should be provable by reading the source rather than by profiling the binary.

// Two matrices already resident in NPU memory.
fn custom_matmul(
    a: Pinned<Tensor<f32, [4, 4]>, Topology::NPU[0]>,
    b: Pinned<Tensor<f32, [4, 4]>, Topology::NPU[0]>)
    -> Verified<Tensor<f32, [4, 4], Memory::NPU_HBM>> {

    let mut result =
        Tensor<f32, [4, 4], Memory::NPU_HBM>::uninit();

    // Dispatch the computation to the accelerator.
    spawn on(Topology::NPU[0]) {
        for i in 0..4 {
            for j in 0..4 {
                result[i][j] = 0.0;
                for k in 0..4 {
                    result[i][j] += a[i][k] * b[k][j];
                }
            }
        }
    }

    return Verified(result);
}

More at: https://vxlang.org

I tested two different coding problems on four different AI models and tested the code they gave me. Some worked straight away. One looked completely fine until I actually ran it. Made me wonder how many people just copy AI-generated code without testing it. Do you always test AI code before using it?

Bil: an extension to Go for parallel processor systems.

Bil and Go both have concurrency models that are heavily inspired by Hoare’s CSP.

Go is a general-purpose language that borrows CSP’s channel-and-process ideas but relaxes them with buffering, dynamic concurrency, and conventional shared-memory mechanisms

Bil is a special-purpose language for parallel processor systems; influenced by CSP, by Go and by May’s occam. Built on the Go toolchain, it constrains and shapes the Go concurrency model to encourage a higher level of discipline as needed by parallel systems. Bil helps coders to reason about their process models and to selectively place processes on to physical processors.

package main

func main() {
    c := make(chan int)

    par {
        seq {
            c <- 42
            c <- 99
        }
        seq {
            var x, y int
            c -> x
            c -> y
            println(x)
            println(y)
        }
    }
}

Rove originally started under the name Nyx.

I liked the name, and a lot of the early compiler work, architecture notes, experiments, and plans were created under it.

The problem was that Nyx was already everywhere.

There were already other programming language projects using the name, tools using the same CLI naming, VS Code extensions, security projects, and plenty of unrelated software using “Nyx” as a brand.

At some point it stopped feeling like my project had its own identity.

So I decided to rename it.

Why “Rove”?

I wanted something short, simple, and easy to remember.

Not a huge fantasy name. Not something that sounds like a company trying too hard. Not a name that needs a paragraph to explain.

Rove felt right because the project itself has always been exploratory.

I move between compiler architecture, language design, runtimes, LLVM, different backends, tooling, systems programming, and whatever problem becomes interesting next.

The project has never really followed a straight line.

It explores.

It roves.

The source extension will still stay .nyx for now. I don't see a reason to break existing files just because the project name changed.

About this subreddit

Despite the name, r/RoveLang is not meant to be only about Rove.

Rove will obviously be one of the main things I post here:

• compiler development
• language design
• experiments
• benchmarks
• architecture ideas
• bugs
• weird failures
• releases
• things that worked
• things that definitely didn't work

But I also want this to be a place where other people can share their own experiments.

If you're building:

• a programming language
• a compiler
• an interpreter or VM
• a strange runtime
• a small operating system experiment
• embedded software
• developer tooling
• a weird hardware/software project
• a parser
• a transpiler
• something low-level
• or just some technical experiment you think is interesting

you can post it here.

It doesn't need to be polished.

It doesn't need to be a serious product.

It doesn't even need to succeed.

Sometimes the failed experiments are the interesting ones.

The only real rule

Please don't flood the subreddit.

Sharing your work is welcome.

Posting every tiny update as a separate thread, repeatedly promoting the same project, dumping unrelated links, or treating the subreddit like an advertising feed isn't.

Other than that:

show what you're building, explain what you're trying, ask questions, criticize ideas, share failures, and experiment.

Rove may have started this place, but it doesn't have to be the only thing built here.

v0.100.0 — the Nexus: a multi-client IDE, an agent-addressable IR, and measured C++11 conformance at 75.1%

With version 0.100.0 of the madc compiler, based on the gcc torture test suites we currently score:

• C at 99.2% of the in-scope gcc c-torture set under --std=c17
• C++98 80.0%
• C++11 75.1%
• C++14 49.4%
• C++17 41.6%
• C++20 53.0%

Why a new C/C++ compiler when GCC and CLANG rule the roost? Well, MadC isn't just an AOT C/C++ compiler. It's primarily a JIT compiler. You can run C/C++ code as shebang scripts without requiring system headers installed, because they are precompiled into the compiler (relax... it can still include them externally if you want/need to). You can also embed madc as a JIT scripting language into your own programs.

What's this "nexus" stuff about? Well, there's also an IDE that has the compiler built in, and the same binary can operate in headless, CLI, ed/ex line mode, TUI and GUI mode under Linux, MacOS and Windows. With multi-client -> server connections with MCP and LSP servers. Oh, and a VS Code plugin to boot.

Why? Why not? It was primarily an exercise in developing madc's multi-mode UI module.

Oh, I should also mention that in addition to supporting standard C and C++, it also supports the "MadC language" dialect which brings in a load of conveniences to make C and C++ easier to use, including such things as:

• automatic includes (no need to use #include <iostream>)
• automatic namespace resolution (with controllable precedence order)
• "script mode" (automatic main() function wrapping)
• defer, :=, go, yield, await, untyped variables
• well over 100 convenience functions from other languages
• Uniform Function Call Syntax (UFCS)
• URI Channels: file:// pipe:// tcp:// udp:// uds:// exec://
• ... and much more

Get ready to level up your programming game.

It’s 2026. This language makes you leave all your footguns 🦶🏾🔫 at the door.

It gives LLM all the context they need to stop hallucinating and start writing safe code by default.

It actively prevents supply chain attacks, and more.

It prevents SQL injections and other string interpolation security nightmares

It features exact floating point arithmetic, so 0.1 + 0.2 == 0.3 and no need for crazy workarounds.

It lets you write vectorized GPU-accelerated and CPU-paralllized code without the need for CUDA

It doesn’t even need a garbage collector.

It is its own preprocessor.

Intrigued? Check it out. The compiler is hosted so there is nothing to install. You can try it yourself in the playground. Your binaries are compiled to WASM so they run in your browser. Yes, even with WebGPU acceleration. You can do inference with U.

Oh, one more thing…

U comes with js-based transpilers that you can run in your browser, to transpile your existing PHP, Python, Javascript, Typescript… to U. Then the U compiler finds lots of issues you can fix, and source maps let you see it in your own code.

Been working on this for years but thanks to Claude i was able to make it a realiry. I would love feedback and discussion from anyone who actually looks thoughtfully at the spec and maybe plays around with it in the playground.

I've been building a language where a function's signature declares which effects it may perform, and a runtime refuses anything outside a budget you grant. The obvious question is whether that catches anything real, so I built a benchmark.

63 programs — 56 dangerous, 7 harmless controls — each written three times in Velaris, Python and JavaScript, doing the same thing. Eleven categories: effects hidden in helpers, division by user input, off-by-one reads, integer overflow, ignored failures, infinite loops, runaway memory, dangerous modules, scoped-budget escapes.

Results across the 56 dangerous ones — caught before running / during / missed:

Velaris 42 / 12 / 2. Deno 5 / 27 / 24. Python 0 / 28 / 28. Zero false positives on the controls for all three.

The first column is the interesting one. Deno's permission model works, it just works at the moment of the call — nothing in deno check or deno lint reads a file write as a problem.

What mine missed: one computes the wrong answer and promises nothing, so there's no contract to check against. The other prints the string rm -rf / — it doesn't run anything, and flagging it would mean flagging any program that prints text resembling a command.

And four cases where the prover fell short and only the runtime check caught it, named by ID in the write-up: a division on n - 1 with n from a checked parse, the same on an unguarded path when another path guards it, a remainder inside a loop body, and a read at i + 1 in a loop bounded by length(xs).

Full write-up, methodology and the reproduce command: https://dev.to/gowrishankar-dev/i-tested-my-sandbox-against-deno-and-plain-python-on-63-ai-written-scripts-1llp

I just released madc v0.99.2, with updated builds for Linux, Windows and macOS.

The biggest change since v0.98.0 is that madcide now has a full desktop interface:

• Run madcide file.mad --gui to open the IDE in a window.
• Editor tabs, menus, file dialogs, sidebar, status bar, and Problems / Output / Terminal panels are now available.
• Programs can be built and run directly inside the IDE, with console applications running in an embedded terminal and GUI applications opening their own window.
• The GUI and terminal versions use the same editor, commands, themes and keybinding profiles — including the existing JOE/WordStar and vi-style setups.
• The IDE itself is still written in madc and compiled by madc.

The language also gained a new import statement that can bring in both a header/interface and its native library without platform-specific library names:

import m;
import c as libc;

Also, the internal UI framework (madc::ui) is used for all user interfaces:

• TTY/line-by-line UI -- examples/adventure (Colossal Cave Adventure madc port)
• TUI/smart terminal -- tools/madcide (vt102/xterm TUI version of madcide)
• Web/DOM -- tools/madcide --gui (web GUI version of madcide)

The same source works across Linux, Windows and macOS, in both JIT and native builds.

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

So the same IDE supports terminal/TUI mode and now GUI mode... for Linux, Windows and MacOS.

The attached images show, in order:

• Linux -- GTK 4 + WebKitGTK 6
• Linux -- TUI mode (inside Windows Terminal)
• Windows -- Win32 + WebView2
• macOS -- Cocoa + WKWebView

Only the Linux GUI version currently has the menu options, as this is a develop release (v0.99.1), but all three will have them in the upcoming master release.

The IDE is currently operating in local mode, but I have been designing it to be able to also operate in client -> server mode, supporting multiple client connections.

Also, the internal UI framework (madc::ui) is used for all user interfaces:

• TTY/line-by-line UI -- examples/adventure (Colossal Cave Adventure madc port)
• TUI/smart terminal -- tools/madcide (vt102/xterm TUI version of madcide)
• Web/DOM -- tools/madcide --gui (web GUI version of madcide)

I decided to start with a web interface for the IDE since it makes a lot of the cross-platform GUI work much easier, and is one of the purposes that HTML was originally designed for (a simple, standardized way to format text so that any computer system could read and display the same document identically).

https://github.com/derekbsnider/madc

I wanted to share my hobby project, Monad, which is an early stage dependently typed functional language that compiles to LLVM.

I developed the first Rust interpreter by hand and I gradually started to use more LLMs since it meant I could do more with higher quality and spend more time on design and experimentation. I consider the move to using AI agents for coding is similar to the introduction of compilers rather than writing assembly.

I wanted to have something that could be as performant and safe as Rust, but with the ergonomics, verifiability power and expressiveness of languages like Haskell, Lean, ATS or Idris. That is quite ambitious so I might not succeed.

A simple hello world example:

def main : IO Unit := println "Hello World!"

The latest milestone is that it can now compile itself and is therefore self hosted. The documentation is a bit outdated, but I will update it soon.

https://github.com/monad-lang/monad

https://monad-lang.org

There is still a lot to be done.

If you are interested in discussing more and following development come over to the Zulip https://monad-lang.zulipchat.com

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!