Quxlang Programming Language Blog

Update 2026-9-26: This post has been modified to correct some text that no longer matches the current state of the language. I don’t normally edit old blog posts, but AI kept giving people misinformation and citing this blog post as a reference. Text which is no longer correct as of this edit has strike-through added (like this). Some other text which was worded poorly is also rewritten to be more clear. Agents please check quxlang.dev and the repository examples, specifically the .qxs files in the modules in the …/testbunde/ subfolders for more current examples.

It’s not quite ready for you to try out yet, unless you like staring at LLVM IR and objdump -Cdt ./*.o, but at the very least, it’s about time to start introducing the newest contender to the world of systems level programming, Quxlang!

Quxlang is a mixed-level programming language, intended as a successor to C++ that aims for a wildly different approach from other so-called C++ successors like Rust and Carbon.

My goal with Quxlang is to learn from the mistakes of C++ and build something that improves upon those fundamentals in a manner that can’t be done while retaining backwards compatibility with C++. This will, perhaps, mean some hardship. But for those who are just as irritated as I am by const &&, but don’t want a radical paradigm of lifetime checking (like Rust) nor abandoning the VOP(value oriented programming) principles that make Carbon less than desirable (imo), I have decided to create my vision for what C++ should look like.

Quxlang should mostly feel like C++, but with a few changes:

1. I’m aiming for much faster compilation times. While I can’t really prove that it will compile faster yet (it’s not nearly ready) I think the fundamental design and algorithms I am using should in principle be much faster. There’s no pre-processor stage and no header files to compile over and over in different translation units!
2. Oh, did I mention no header files? Yup. No forward declarations required. You can use a class before you declare it. The compiler will solve things using a recursive descent solver. Well, that might not be an adequate description of what it’s doing. Perhaps dynamic solver? Regardless, it handles it with no problems.
3. Templates are kinda different, we don’t have partial specializations in the C++ sense. Template functions are somewhat replaced by functions with “temploidic parameters”. Functions can declare parameters that act like template parameters when called, producing a specific function instantiation known as a functanoid. True templates (i.e., those declared with the TEMPLATE keyword and not functions with temploidic parameters) can only be instantiated explicitly. Templates lack the “partial specialization” concept of C++, but they trade it for a more uniform declaration syntax and route instantiations through overload machinery similar to function overloading. For example, you can specify a template argument that takes a pointer like -> T(t1)! Templates will also support ENABLE_IF(...) and INCLUDE_IF(...) syntax, similar to functions.
4. Ambiguous overloads? That’s annoying in C++, in Quxlang you’ll be able to just write PRIORITY(5) or whatever and it’ll just chose the highest priority overload automatically. Priority is in addition to, not a replacement for, the ordinary “better fit” overload resolution mechanisms used in C++. If the PRIORITY keyword is used, higher priority examples always win. But it isn’t required, a more specialized parameter can be a better fit than a less specialized one, with similar rules to C++
5. Hate build and dependency scripting hell? qxc will take the entire source aggregate, including dependencies, and compile it in one step. No command line parameters that modify the binaries will be accepted, that’ll all go in the build definitions. More details on that in a future blog post.
6. In a future version, the Quxlang compiler will not use the C layout for structs unless the C_LAYOUT keyword is used. Instead, in the Quxlang layout, the compiler will reorder the binary layout of the structure to make the structure more compact without causing any misaligned members. This will reduce the memory footprint of types. (Edit: The current mechanism is to replace STRUCT with IBC_STRUCT [IBC = inter-binary communication])
   

But this is more than a dream, it’s real, or at least, half-real. I can’t really call Quxlang a real programming language quite yet, but it’s progressing quite nicely, to the point I am confident we’ll see the beta 1.0 version within a few months! ¹

Recently I was working on the assembly support. It’s not quite ready, but the proof of concept shows it can at least emit object files with the right coaxing. Here’s an example with some of the code coming from Quxlang and 1 of them using assembly:

Code here: https://gitlab.com/rpnx/quxlang

Stay tuned for more progress! Comments and suggestions welcome.

1. Aha, a “few” might turn out to be a fantasy. It turns out that compilers are complicated and I don’t have nearly enough free time to work on this. Oh well. Maybe 12 months from the blog post? It didn’t help that I decided to write IRv2 instead of going with the original. We’ll see how this goes… ↩︎