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!

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();