One Year of Contributing to C3

module main;
import std;

fn void main()
{
	String[] greetings = {
		"Hello, world!",
		"¡Hola Mundo!",
		"Γειά σου Κόσμε!",
		"Привет, мир!",
		"こんにちは世界！",
		"你好世界！",
		"नमस्ते दुनिया!",
		"👋🌎!"
	};
	foreach (greeting : greetings)
	{
		io::printn(greeting);
	}
}

I started hacking on C3 about a year ago without any real agenda.

Usually when I contribute to open source, it's just fixing a bug in something I use so I can get back to work. C3 was different. The language already solved most of my grudges with C, but almost nobody was actually maintaining it. Great syntax doesn't matter much if the tooling around it is a pain in the ass.

I started where the friction was worst: running tests. CI runs took anywhere from two to four hours, and running the suite locally took long enough that you'd lose track of what you were doing. I rewrote the test runner to run in parallel, cleaned up the CI config, and got local runs down to under a minute (and CI down to ~20 minutes).

Once testing wasn't painful anymore, the next obvious problem was discovery. The standard library was basically undocumented; if you wanted to know what functions existed, you had to grep through compiler source. So I wrote docgen: the compiler side to dump a complete JSON export of your codebase (or stdlib), and a browser viewer with fast search to jump straight into the code.

Around the same time, the project's web presence needed help. The old site was clunky, so I rebuilt c3-lang.org with MkDocs, added a nice search, and set up a daily job to deploy the docgen output directly so the stdlib documentation stays up to date.

That web work led directly into another missing piece: letting people try the language without installing it. After patching the compiler to build under Emscripten, I built the C3 Playground. It runs the compiler directly in WebAssembly and bundles Raylib, so you can test code and run full graphical demos like Neon Overdrive in the browser without installing anything locally.

Beyond documentation, cross-compilation was another headache. Targeting Windows from Linux requires Microsoft's SDK headers and libraries, which previously relied on a separate Python script we shipped alongside compiler releases. Having a standalone systems compiler depend on a Python runtime just to fetch cross-compilation libraries felt messy. I rewrote the whole process in C (including a native MSI database unpacker) and baked it directly into c3c fetch-sdk. Now the compiler fetches and unpacks the SDK entirely on its own.

The standard library had similar gaps where it was still leaning on external C libraries for basic tasks. A systems language shouldn't need foreign wrappers just to handle everyday formats. I wrote pure C3 implementations for ZIP and DEFLATE, built a zero-copy regex engine that works straight on slices, wrote a streaming XML parser, and lately I helped wire up Wayland and web support for the graphics library.

Editor tooling was another weak spot. Most people expect a working language server, but c3_ls wasn't there yet. I finally made time to dig into it, and c3_ls is now in a mostly functional state. As part of that work, it also gained a bindgen tool to convert C headers directly into C3 declarations, cutting down the friction of binding foreign libraries.

Working on the docgen allowed me to familiarize myself with the c3c compiler codebase and eventually, I ended up working on the C backend. This was a big one.

LLVM is fine for optimizations, but it's massive, slow to build, and eats RAM. It also ties C3 to whatever targets LLVM supports. I wanted C3 to compile without dragging LLVM along everywhere, so I started writing a C backend to spit out plain, portable C code. It took a lot of work to make sure things like overflow trapping, 128-bit ints, and memory layouts behaved the exact same way they do under LLVM. It isn't finished yet, but using Clang it is almost on par speed-wise with the LLVM backend, though still lacking a few C3 attributes.

A year in, I didn't plan on touching half this stuff. I just fixed one bottleneck, which led to the next, until I was working on core compiler internals. There's still plenty left to do.

Every addition to C3 has to be maintained, and right now that burden falls on a very small handful of people. If we want more ideas merged, we need more people willing to maintain the plumbing, whether that means fixing bugs in the compiler, filling out the standard library, or helping with the docs and playground tutorial examples.