Skip to content

Overview

Quxlang is a multi-paradigm systems programming language. In most respects, it offers a similar niche to C++, with some noteworthy differences.

Guiding Lights:

  • Deterministic, Reproducible & Hermetic Development. The same version of the compiler should produce the same output given the same input, regardless of the environment in which it is run. Automatic updates and using hidden system libraries imperils the predictability and auditability of the software supply-chain.
  • The Compiler is a Compiler, not a Package Manager. Hermetic Development doesn't mean that software libraries shouldn't be updated, it just means that this isn't the job of the compiler to solve. No compiler should throw blind trust at an organization to hopefully not backdoor your XZ library.
  • Running the Compiler Must Be Safe. Launching the compiler on untrusted input should never be a security risk, although running the produced binaries might be. The worst the compiler can do to your system is use 100% of your CPU, use up whatever RAM is made available to it, or spit out large binaries that use up your disk space. We should be able to hermetically reproduce builds without relying on arbitrary code execution that might be malicious. A build server should be able to safely run builds without needing the overhead of a VM.
  • Value and data semantics are the core programming model. Various defaults in the language assume things like strong ordering and canonical representations for datatypes. Quxlang prefers the C++-style value-copy model to the reference model adopted by languages like Java and Python.
  • Provide negative-overhead abstraction. Abstractions should make the program faster, not slower.
  • Don't be helpful. Also known as "Avoid Causing Problems"; it is better to leave a problem unaddressed at the language level than provide a bad solution. Another way to phrase this rule is for the language to avoid making choices for the programmer.
  • Don't break code. Design to maintain backwards compatibility of code. This is the main reason all keywords are UPPERCASE and there is a version specifier at the top of each file, new keywords can be added without breaking old code, and behaviors can be changed in new versions without causing existing code's behavior to change. The compiler shouldn't require you to rewrite correct code based on the latest fad of the month. Note that this rule only applies to stable releases, syntax introduced in experimental and development versions may be changed. Note also it's possible some new and old features might not be usable together due to compatibility breaks (for example, if version 2.0 changes virutal function call behavior, it might not be possible for an object declared in a version 2.0 file to inherit from an object declared in a version 1.0 file). This should be understood without stating it, but to be explicit, the backwards compatibility guarantee also doesn't apply to any undefined behaviors.
  • No training wheels. While we want programming to be as easy as practical, sometimes decisions must be made where a choice must be made between what is most useful to beginners and what is most useful to experienced programmers. Quxlang is foremost a serious tool for serious development, and the utility of the language must be prioritized over ease of use for new developers.
  • Reasonable Safety Mechanisms. Sometimes you need sharp knives and big guns to solve big problems. Where reasonable, we can put safety mechanisms on the guns and knives. Having safety mechanisms doesn't mean we can't use sharp knives and big guns, it means we may sometimes need to use a safety lever or pull the knife out of its sheath to use it; the language isn't going to protect you against every possible hazard, but we can put safeties up around the most hazardous bits.
  • There is no layer beneath compiled Quxlang. Quxlang doesn't require a runtime written in C or another language compiled in to operate. Quxlang programs are compiled with a runtime written in Quxlang. If you need to do system calls or device drivers in assembly, you should be able to express that assembly in the Quxlang language. Unlike C and C++, which are "incomplete" languages which can only invoke assembly through vendor-specific language extensions, assembly is integrated into the Quxlang language as a first-class citizen. In principle, you should be able to write an OS kernel in pure Quxlang (although support for all features needed to do this is not yet implemented). This doesn't nessecarily mean that the compiler itself is implemented entirely in Quxlang (rewriting LLVM would be a massive undertaking), but rather that useful binaries entirely written in Quxlang should be possible.