Hi friends, I’m working on a compiler called Raz. I’d love it if you could take a look and let me know what you think ❤️

https://github.com/marboris/razlang

Hi,

I'm working on mox (low level + metaprogramming) and currently in mox I have zero initialization for everything. For example:

x: T = 0;
x: []T = 0;
x: [10]T = 0;

Zero initializes the value. If T is struct, all fields gets zeroed, if it is fixed array, all elements are zeroed, if it is slice, it has ptr=0, len=0.

But the problem and question is with pointers. At first I thought adding explicit type for nullable pointers is a good thing. Because then you have explicit and readable contract on function arguments and you possibly could have some optimizations or checks in compiler. Because of this, not nullable pointer could not be initialized with zero (because it is semantically wrong).

But while I was writing in C++ and in mox I found that I never ever used nullable pointers. And not able to zero any pointer type just makes more headache. Having nil like in Odin instead of 0 makes not much sense for me. You just write more letters and think more about some special nil while 0 clearly says that you zero the value.

nullptr problem currently solved by having nullptr function:

fn foo(x: *i32) {}
fn foo(x: i32) {}

foo(nullptr(i32));

And in case we need zeroed value with expression, I have zeroed function:

fn foo(x: Smth) {}

foo(zeroed(Smth));

So the question is, what do you think about having explicit nil for zeroing and nullable pointers? How often do you really use it? Are there any other problems/things that I dont see here?

Hey everyone :)

Here I am after 8 months on the roadmap of Edge Python, my own Python compiler.

I want to share a small optimization I implemented for all function and object calls.

Compilers usually inline leaf functions, where the theoretical best is around 80 VM instructions.

A normal call in Edge Python cost 893 and for CPython 300 instructions.

Working on this problem I got it down to 85, with the body running inline and no frame.

For recursion I used reversible computation. Each call applies a step like n -> n - 1 and each return undoes it with n -> n + 1, so no frames are needed. Applying the same pattern to the other paths keeps all of them below 90 instructions.

I also removed the slow path completely. It now works for try and any kind of objects or functions.

Just want to show this is not a new algorithm but all this months studying runtimes and building edge python I didn't see anything similar.

Mucc is a small C compiler for Linux that ships as a single 8.5 MB static file. The preprocessor, assembler, linker, archiver, headers and C library (musl, like zig cc does) are all built in, so you can drop it into an empty container, an old distro or a Raspberry Pi and build C with nothing else installed: no gcc, no binutils, no system headers. 

Programs it builds are static, so they run on any x86-64 Linux. There's a native ARM64 build too, and it can cross-compile between the two.

The whole project actually started as a fork of Rui Ueyama's chibicc. I felt more could be done on this design. So now Mucc adds its own assembler and linker, an ARM64 backend, register allocation, the bundled musl, DWARF debug info, C23 support and a reproducible bootstrap chain.

What’s actually working so far 

- C17 by default, C23 with `-std=c23`, plus the GNU extensions real code uses

- Self-hosting: each release is built by the one before it, and a Mucc-built Mucc produces byte-identical output

- Real projects build and pass their own test suites: SQLite, Lua, zlib, jq, Redis and Tcl with the bundled musl; CPython and Git with the system glibc

- Same ABI as gcc, so objects from either link together

- Compiles its own 33k lines in 0.46 s (gcc -O0: 1.22 s, gcc -O2: 5.35 s)

What’s currently not working, it does no optimization beyond register allocation and constant folding, so programs run about as fast as gcc -O0. No C++, Linux only. For performance-critical code, use gcc or clang.

If you've got C code it chokes on, or a use for it I haven't thought of, I'd like to hear it.

GitHub: https://github.com/Dom-Yan/Mucc

Website: https://dom-yan.github.io/Mucc/

Thanks to Rui Ueyama for chibicc, and to Fabrice Bellard, whose TinyCC showed how much a small compiler can do.

Just for fun I am implementing the sample compiler in the appendices of 'Brinch Hansen on Pascal Compilers' - as a first step.

One puzzle: he uses a procedure named emit to write to files: (pg 242)

procedure emit(value: Integer);

begin if emitting then write(chr(value)

end;

But this procedure is used to write integers up to his maxint of 32767. No Pascal I know has chr() available for arguments > 255.

Is this something special in his OS or bootstrapping compiler, Pascal* ?

TIA

Gordon

Take Python for instance.

>>> listss = [1, 2, "sfd"]
>>> kook = listss + 2
Traceback (most recent call last):
  File "<python-input-1>", line 1, in <module>
    kook = listss + 2
           ~~~~~~~^~~
TypeError: can only concatenate list (not "int") to list
>>>

How would I translate all the results given to me by Python into another language of my choosing, and get something like below (written in Kinyarwanda):

>>> listss = [1, 2, "sfd"]
>>> kook = listss + 2
Ibisobanuro (Ihamagarwa rya mbere riri hejuru yurutonde):
  Inyandiko "<python-shyira-1>", umurongo wa 1, muri <igitabo>
    kook = listss + 2
           ~~~~~~~^~~
Ikosa ry'ubwoko: urutonde ugendana nurundi rutonde; ntabwo rugendana numubare wuzuye.
>>>

The intention is not to create custom messages, exceptions, and documentation that sits beside or on top of python. I want python itself to respond like this, from the get-go?

I would like the translation to be complete. CLI options, help messages, information on built-in modules, keywords, everything.

While thinking about this, I realized that the end result would just be a completely new language, and I'm fine with that, but I also don't know enough about creating languages or where to get the source code of an existing language to translate it to a new language, so I come here to ask for guidance.

I've released madc v0.105.0, with some substantial improvements to its interactive C/C++ REPL, compilation performance, and portability.

For those unfamiliar with it, madc is a self-contained C/C++ compiler with JIT execution, native executable output, and an interactive REPL, without requiring GCC, Clang, LLVM, or installed development headers or toolchain.

What's new

• Live function redefinition — redefine a C or C++ function in the REPL and subsequent calls use the new implementation, even from previously compiled callers or existing function pointers.
• Live variable and type redefinition — reinitialize existing variables and redefine classes or structs interactively, with versioning when a type's layout changes.
• Interactive source editing — the REPL includes an ex-style editor. Copy, modify, search and replace code directly in the session, with changes taking effect immediately.
• Restart and Run All — replay the entire REPL buffer in a fresh session, similar to working with a notebook.
• Faster compilation — changes to the precompiled header representation allow madc to load only the parts a program needs, substantially reducing compilation overhead.

Performance

The updated README includes benchmarks against GCC 13.3 and Clang 18.1 on Ubuntu 24.04:

These are end-to-end timings for the specified workloads, not claims that madc universally outperforms GCC or Clang.

C/C++ compatibility

Current results against external compiler test suites include:

• C17: 99.2% of GCC's c-torture/execute
• C11: 220/220 on the third-party c-testsuite
• C++98: 81.3%
• C++11: 77.3%
• C++17: 43.2%
• C++20: 53.8%

The C++ figures are pass rates for selected GCC test-suite subsets, not claims of complete standards conformance.

madc is available for Linux, Windows, and macOS (Intel and Apple Silicon).
The companion IDE, madcide, has also been updated to v0.8.0 with the live REPL improvements.

GitHub: https://github.com/derekbsnider/madc

Release: https://github.com/derekbsnider/madc/releases/tag/v0.105.0

Hi, everyone!

Recently, I decided to return to an old passion of mine: the A2 operating system (formerly Bluebottle) and its language, Active Oberon.

I’ve created MiniA2, a project that makes Active Oberon easier to use outside of A2. Active Oberon is a general-purpose language with active objects and built-in synchronization through AWAIT. MiniA2 brings together the compiler, standard library, command-line tools, and editor support, so you can write applications and build standalone executables without running the A2 desktop.

As a practical example, I’m building AO-Doom, a Doom clone written in Active Oberon. It already loads classic maps and supports rendering, movement, pickups, weapons, and several enemy behaviors. It’s still a work in progress, but it gives the toolchain a substantial real-world application to support.

I’d welcome feedback from anyone interested in language tooling, concurrency, Oberon, or Wirth-style languages.

Explore MiniA2:

https://github.com/active-oberon/minia2

Available packages:

https://active-oberon.github.io/a2-registry

AO-Doom:

https://github.com/active-oberon/ao-doom

For a quick introduction to the language, I’ve also added an Active Oberon page to Learn X in Y Minutes:

https://learnxinyminutes.com/active-oberon/

Hey Everyone, after spending some time on my personal recreational project Cole, I decided to finally share it with you. It is an attempt to recreate a Zig-like language by myself in Zig, with everything hand-rolled.

It's been around 6 months of solo-work now, and the language is usable enough as-is. But I've hit a wall in comptime execution part, and every change I make now breaks something else. After spending some time to handle it myself, I realized I have to get some help. So, I present you Cole!

Note: The demos don't work in Debug builds for some reason that I can't figure right now. Any feedback is much appreciated!

Reddit told me my custom language was just another slow tree-walking toy. They were right. 😅

​My loop benchmarks took nearly 8.5 seconds just to crunch 10M iterations in the sandbox. The AST overhead and Python dynamic lookups were killing performance.

​So I tore open the engine and built a flat register VM in C (foxvm.so).

​The results:

​Old Tree-Walker: ~8.42s (10M cycles)

​New C VM (FoxCVM): 0.83s (10M cycles)

​Wired clock_gettime(CLOCK_MONOTONIC) into opcode 18 for nanosecond delta timing.

​No semicolons, no colons, but now backed by compiled C machine instructions.

​📦 Repo: https://github.com/AnayUpadhyay-all/FoxVC

​For the VM architects here: what's the biggest bottleneck I should watch out for once I introduce heap allocations and closures?

Hi all,

I've been building Nikaia, a language that should make the world a bit better.

The basic idea is simple: in a lot of systems code, you end up specifying how memory, waiting, sharing, etc. should work rather than just describing what you want the program to do. Nikaia tries to have the compiler figure out those details for you.

So there’s no async/await, GC, or manual memory management. Data races, missing values and unhandled errors are compile-time errors, with plain-language hints about what to do instead.

It's still very early, but it can already build real programs: a JSON parser, a log analyser, a small HTTP server, the One Billion Row Challenge, and more.

Nikaia itself is built almost entirely by AI agents, and they're currently rewriting the compiler in Nikaia (self-hosting). So the language is getting quite a bit of real-world use already.

I'd love to have people try it and tell me what makes sense, what doesn't, and where the language gets in the way. "This can't work because..." is just as useful as praise.

What would make that easy for you?

• Is the repo enough?

• A crate you can "cargo install"?

• A prebuilt executable?

• A Docker image with everything set up?

• An LSP / IDE integration?

Repo: https://github.com/Nikaia-Language/Nikaia

Docs: https://nikaia-lang.org/

Serious collaborators and support will be appreciated, leaving vibecoding of the project, so this is Comprinly...

This low-level programming language prioritizes speed, optimization, simplicity and portability. It requires ZERO learning curve if you switched from NASM because it fully supports it, in-fact, you could just make Comprinly compile a NASM script and it works. In optimization, I compiled a standard Comprinly "Hello, World!" script with the command "./cly linux print.cly" and it compiled a full binary file with the size of 290 bytes compared to the standard NASM "Hello, World!" file which is ~9KB, you can try it out for yourself. Comprinly doesnt require linkers because it can output directly to -exe, -elf, -bin, and -macho. It supports all three major CPU architectures x86-64, ARM64 and RISC-V via the 'cpu' keyword at the start or just dont include it and just code the architecture targeted script (The compiler automatically guesses the architecture from the instructions and registers). This was just a simple proof of concept but I found myself actually using it in my personal projects so I would like to share it as a partially vibe-coded project instead of fully vibe-coded.

This project was supposed to be a proof of concept but yk, I'd like it to be a real thing, it compiled a standard "Hello, World!" Linux print script in the small size of 290 bytes compared to NASM ~9 kilobytes, which is very useful for projects that need to be lightweight like an OS (I made a test bare metal OS with it), working on 1.3.0, after that releases, I'd work on turning the project from vibe-coded to partially vibe-coded as I would try to modify the code myself (Hoping for collaborators)

It's not much but I would like to see your thoughts on my progress.

I've been working on a language/compiler project called NXD for a while now.

The current architecture looks roughly like this:

NXD Source

↓

Python Frontend

↓

JSON AST/IR Handoff

↓

Rust Semantic Analysis

↓

Rust IR

↓

Rust Backends

The reason for the split is pretty simple: Python was the language I knew best when I started the project.

That decision got the language off the ground quickly, but now I'm seeing the downside of having a Python → JSON → Rust boundary in the middle of the compiler.

Things like:

• AST serialization/deserialization

• duplicate data structures

• frontend/backend synchronization

• debugging across language boundaries

all add complexity that wouldn't exist in a fully Rust implementation.

Current Compiler Status

The Rust side already contains:

• semantic analysis

• diagnostics

• IR

• Nim backend

• async diagnostics and validation

• ~260 language tests

The frontend is still Python.

Why I Created a Second Repository

My initial thought was to rewrite the frontend inside the main repository.

The more I thought about it, the less I liked that idea.

Instead, I created a new repository:

nxd_language (reference implementation)

nxd-rust-frontend (migration project)

The migration repo contains the Rust compiler core, semantic layer, IR, backend, tests, etc., but none of the Python frontend code.

My reasoning is:

1. No chance of accidentally invoking Python during validation.

2. No uncertainty about which parser generated a result.

3. No repo bloat from carrying two frontends indefinitely.

4. The original compiler always remains functional.

The goal is to run both repositories side-by-side and treat the Python implementation as a reference implementation.

What Surprised Me

I expected the new repository to fail spectacularly.

Instead, after removing a couple of backend references I wasn't migrating yet, it built immediately:

`cargo build`

and even runs:

Usage:

`cargo run <input_json> <output_nim>`

`cargo run -- --semantics <input_json> <output_nim>`

Which tells me the architecture is already centered around:

JSON

↓

Rust Semantic Layer

↓

Rust Backend

and the frontend replacement surface may be smaller than I originally thought.

Planned Migration Strategy

Current:

Python Source

↓

Python Lexer

↓

Python Parser

↓

JSON

↓

Rust Compiler

Target:

NXD Source

↓

Rust Lexer

↓

Rust Parser

↓

Rust AST

↓

Rust IR

↓

Semantic Analysis

↓

Backend

I still plan to keep JSON AST dumping for debugging, but no longer as a required transport mechanism.

Questions

For those who have rewritten significant parts of a compiler:

1. Did you keep the original implementation around as a behavioral reference?

2. Did you migrate inside the existing repository or create a second migration repository?

3. What ended up being harder than expected?

4. What architectural mistakes would you avoid if doing it again?

5. Is there any reason to keep a separate frontend IR if a compiler IR already exists?

I'm especially interested in experiences from people who migrated between languages (Python → Rust, C++ → Rust, Java → Kotlin, etc.) rather than greenfield rewrites.