DEV Community: Karac Thweatt

The Language After Rust and Zig

Karac Thweatt — Tue, 14 Jul 2026 23:00:34 +0000

Systems programming has been having a moment. After decades of C and C++ as the only real options for performance-critical work, two serious challengers arrived and changed the conversation. Rust pushed the idea that memory safety and zero-cost abstractions can coexist, backed by a borrow checker that enforces ownership at compile time. Zig pushed back by arguing that simplicity, explicit allocation, and comptime evaluation are more honest than a borrow checker, and that the right amount of language is less, not more.

Both made real contributions. Both have production users, strong communities, and codebases to prove the ideas work. But a newer language called Flux is asking a different question entirely: what if the language trusted you to be a programmer, gave you powerful and composable primitives, stayed out of your way where you didn’t need it, and offered safety tools you could reach for by choice rather than mandated throughout? What if you could have hardware-level control over memory layout, arbitrary-width integer types, opt-in ownership semantics, compile-time contract enforcement, and macro-level metaprogramming, all in a language that reads as cleanly as anything else in the C family?

This article is an honest comparison. Not a hit piece on either Rust or Zig — both are serious work by serious people. But the tradeoffs they made are real, and Flux makes different ones.

The Ownership Problem
Rust’s borrow checker is its most famous feature and its most famous source of friction. The core promise is compelling: by tracking ownership and lifetimes throughout your program at compile time, the compiler can guarantee that no two pieces of code mutate the same data simultaneously, that no use-after-free ever occurs, and that no data races are possible in safe code. When it works, it is remarkable. Programs that compile are, in a meaningful sense, correct with respect to a large class of memory errors.

The cost is real though. You annotate lifetimes on functions three layers deep. You reach for Arc<Mutex<T>> to share state between components in a way that would be two lines in C. You fight the borrow checker over patterns that are obviously correct to a human reader but opaque to a system that must be conservative. The borrow checker is an all-or-nothing proposition: either your entire program is in the system, or you are in unsafe and writing C inside a Rust wrapper. There is no middle ground where you say "I want move semantics on this specific type, but I don't need the compiler tracking every reference in this module."

Zig went the other direction. There are no ownership semantics in the Zig type system at all. Memory safety comes from discipline, explicit allocators, and defer for cleanup. Every function that allocates takes an allocator as a parameter. Nothing is hidden. You know exactly where memory comes from and where it goes because you wrote it. This is honest and predictable, but it leaves the safety guarantees entirely to the programmer's discipline and code review.

Flux sits between the two, and the solution is the tie operator ~. Ownership in Flux is opt-in at the type level. You apply it to the types and values where it matters, and the rest of your program runs without ownership overhead of any kind, mental or compiled.

The rules for tied values are deliberately simple:

A tied value must be explicitly untied on use with the ~ prefix
A tied value can only move to a parameter or variable of tied type
Once a value is untied, the original reference is invalidated — use after untie is a compile error

def foo(~int z) -> void  // accepts a tied parameter
{
    return;
};

def main() -> int
{
    ~int x;
    int  y;
    foo(~x);   // Untie x from main's scope, tie it into foo's parameter
    foo(~x);   // Compile error: x has already been untied
    foo(y);    // Compile error: foo expects a tied parameter, y is not tied
    return 0;
};

You use this where you actually want it: a raw buffer being handed to an allocator, a file handle that must not be duplicated, a socket that should have one owner. Nowhere else. Nowhere you did not ask for it. The compiler enforces the contract on those specific types while your hash table, your string buffer, and your integer math proceed without a borrow checker in sight.

This is also consistent with Flux’s broader philosophy: the type system gives you tools you compose deliberately, rather than a global constraint you live inside.

Compile-Time Execution
Zig’s comptime is one of its best ideas. You mark code comptime and it runs during compilation using the same syntax as runtime code — no separate macro language, no special rules for what you can and cannot write. It is just Zig, running at compile time.

Flux has the same property, and then goes further in almost every direction.

Compile-time code in Flux is Flux. You wrap code in a comptime block and it executes during the compiler's code generation pass, on a dedicated virtual machine — the FVM — that was built specifically to handle compile-time execution and also powers the REPL. You can define functions, declare variables, call functions, do I/O, run loops, branch on conditions — anything you can do at runtime, in the same syntax:

#import <standard.fx>;

comptime
{
    def foo() -> void
    {
        compiler.io.console.print("Hello from compile time!\n");
    };
    foo();
};

def main() -> int
{
    return 0;
};

This prints Hello from compile time! during compilation, interleaved with the compiler's own output. Multiple comptime blocks share scope — functions defined in one are callable from another, and variables persist across blocks.

Rust has no equivalent to this. const fn is a restricted subset of the language that excludes most interesting operations. Procedural macros run at compile time but are a completely separate Rust program operating on token trees, not a Rust function running in the same language with the same syntax. The mental model is fractured across three separate systems. In Flux, compile-time code is just code.

The FVM goes deeper than that. Because the compile-time executor is a real virtual machine with its own instruction set, you can drop into raw FVM assembly inside a comptime block using a fluxvm block, operate directly on comptime-scope variables, and have those modifications visible to subsequent Flux comptime code:

comptime
{
    int x = 5;

    fluxvm
    {
        LOCAL_GET x
        PUSH 10
        ADD
        LOCAL_SET x
    };
    compiler.io.console.print(f"FluxVM modified int x = {x}\n");
};

After the fluxvm block executes, x is 15 and the print statement sees that value. The FVM instructions operate on the same variable table as the surrounding Flux comptime code. This is not a simulation or a separate address space — it is the same VM that is running the comptime execution, exposed directly.

And you can dump the FVM assembly of your comptime code to a file for independent execution:

compiler.fvm.dump("my_comptime.fvm")

That file can be executed standalone by the FVM outside of a compilation, which means comptime logic can be extracted, inspected, shared, or reused as independent programs. The compile-time executor is not a black box baked into the compiler. It is a documented, accessible VM with a text assembly format you can read and write directly.

Compare this to Zig: Zig’s comptime also runs the same language at compile time, which is the right idea, but the compile-time executor is an internal interpreter with no exposed instruction set, no dump capability, and no path to independent execution. What Flux adds is the full stack — a real VM, a readable assembly format, direct inline access to that VM from comptime code, and the ability to treat comptime programs as first-class artifacts.

Zig also does not have an equivalent to emitflux, which is covered in the next section.

Named comptime blocks add another dimension entirely. A comptime block can be given a name, and any comptime code can goto that name like a label. Because comptime blocks share scope, jumping between two named blocks repeatedly is a valid loop:

comptime A
{
    // setup or per-iteration work
    goto B;
};

comptime B
{
    // more work
    if (condition) { goto A; };   // loop back
    // otherwise fall through and stop
};

This means the control flow of your comptime execution is not limited to the structured loops and branches inside a single block. You can build arbitrary comptime control flow graphs out of named blocks, with goto as the edge. Combined with emitflux, this means the structure of your code generation can itself be driven by non-linear comptime execution — not just a single loop that emits things in order, but a full state machine at the meta level that decides what to emit and when based on conditions that evolve across block boundaries.

Code Generation with emitflux
An emitflux block inside a comptime block injects Flux code into the compilation unit at the scope where the enclosing comptime block lives, in the order the emitflux blocks appear. The comptime code is the generator. The emitflux blocks are the output — real Flux definitions that land in the file as if you had written them there by hand, fully type-checked, compiled, and available to the rest of the program.

The practical consequence is that you can drive code generation with arbitrary Flux logic running at compile time: loops that iterate over data, conditionals that branch on computed values, string interpolation and codification that build identifiers from comptime variables. Whatever the comptime execution produces gets emitted as concrete Flux into the module.

Here is a complete example — a state machine where the valid transition predicates are generated from a data table rather than written by hand:

#import <standard.fx>;

using standard::io::console;

enum State { Idle, Running, Paused, Stopped };

comptime
{
    int[] trans_from = [0, 1, 2, 1];
    int[] trans_to   = [1, 2, 1, 3];
    int   tcount     = 4;
    emitflux
    {
        def state_name(int s) -> byte*
        {
            if (s == 0) { return "Idle"; };
            if (s == 1) { return "Running"; };
            if (s == 2) { return "Paused"; };
            if (s == 3) { return "Stopped"; };
            return "Unknown";
        };
    };
    for (int tidx = 0; tidx < tcount; tidx++)
    {
        emitflux
        {
            def ~$i"can_trans_{}_{}":{trans_from[tidx];trans_to[tidx];}() -> bool { return true; };
        };
    };
    emitflux
    {
        def transition(int fx, int to) -> int
        {
            if (fx == 0 & to == 1 & can_trans_0_1()) { return to; };
            if (fx == 1 & to == 2 & can_trans_1_2()) { return to; };
            if (fx == 2 & to == 1 & can_trans_2_1()) { return to; };
            if (fx == 1 & to == 3 & can_trans_1_3()) { return to; };
            println(f"Invalid: {fx}:{state_name(fx)} -> {to}:{state_name(to)}");
            return fx;
        };
    };
};

The comptime loop runs four times. Each iteration emits one can_trans_X_Y() function into the module scope. The function name is built from the transition table values: ~$ is the codify operator — the inverse of stringification, turning a string into a valid code identifier — combined with an i-string that interpolates the comptime variables into the name. By the time the final emitflux block emits transition(), all four predicate functions already exist in the compilation unit because they were emitted in order above.

The result is a complete, type-checked state machine. Adding a new valid transition means adding one entry to the comptime data arrays. The predicate functions, the transition() dispatcher — none of that is touched. The generator produces it all.

This is what Rust’s procedural macros are attempting to do. But in Rust, that requires a separate crate compiled as a separate program, a separate registration mechanism, and working with token tree manipulation through an API that is distinct from ordinary Rust. You are not writing Rust — you are writing a Rust program that writes Rust tokens. In Flux, you write Flux that writes Flux. Everything is in one file, in one syntax, with a direct and readable relationship between generator and output.

Expression Macros
Separate from comptime, emitflux, and the FVM, Flux has expression-level macros for inline call-site substitution. A macro definition looks like a function but expands before code generation, substituting its arguments into an expression at every call site:

macro xyz(a, b, c)
{
    (a + b) ^ c
};

println(f"xyz(1,2,3) = {xyz(1, 2, 3)}");
// Expands to: println(f"xyz(1,2,3) = {(1 + 2) ^ 3}")
// Prints: xyz(1,2,3) = 27

The macro body is an expression, not a statement list or a token tree. It cannot inject control flow into a call site. It substitutes its arguments and the resulting expression appears at the call site. Macros compose cleanly with contracts — a contract can use macros, and both attach to functions or operators through the same syntax:

macro macNZ(x)      { x != 0 };

contract ctNonZero(a, b)
{
    assert(macNZ(a), "a must be nonzero");
    assert(macNZ(b), "b must be nonzero");
};

Macros can also be self-referential, allowing recursion:

#import <standard.fx>;

using standard::io::console;
macro factorial(n)
{
    n * factorial(--n) if (n > 1) else n
};
def main() -> int
{
    int x = factorial(5);
    println(x); // 120
    return 0;
};

Here’s a more advanced example of metaprogramming in Flux:

///
    metademo.fx -- a CLI calculator whose dispatch is built entirely
    at compile time via comptime + emitflux.

    metaprogramming techniques used:
      - macro          : compile-time expression helpers
      - comptime       : generate code and print build-time diagnostics
      - emitflux       : inject generated Flux source into scope
      - $              : stringify identifiers into byte* names
      - ~$             : codify strings back into identifiers / source
      - i-string       : build identifier names from loop variables
      - g-string       : deduplicated global string constants
      - self-ref macro : FVM-evaluated factorial baked in as a constant
///

#import <standard.fx>;

using standard::io::console;

// -------------------------------------------------------------------
// Step 1: macros
// -------------------------------------------------------------------

macro clamp(v, lo, hi)
{
    (v if (v > lo) else lo) if ((v if (v > lo) else lo) < hi) else hi
};

// self-referential -- FVM constant-folds entirely at compile time
macro ct_fact(n)
{
    n * ct_fact(--n) if (n > 1) else n
};

// stringify a variable name and print it alongside its value
macro named_print(val)
{
    println(f"{$val} = {val}")
};

// number of ops -- change this and everything below regenerates
#def NUM_OPS 4;

// -------------------------------------------------------------------
// Step 2: comptime generates one handler per op, a dispatch function
//         with a generated switch body, and a names table
// -------------------------------------------------------------------

comptime
{
    byte*[NUM_OPS] op_names = ["add", "sub", "mul", "div"],
                   op_syms  = ["+",   "-",   "*",   "/"],
                   op_exprs = ["a + b", "a - b", "a * b", "a / b"];

    compiler.io.console.println("[comptime] generating op handlers...");

    // emit one handler function per op
    int i;
    byte* nm, expr;
    while (i < NUM_OPS)
    {
        nm   = op_names[i];
        expr = op_exprs[i];

        compiler.io.console.println(f"[comptime]   op_{nm}");

        emitflux
        {
            def ~$i"op_{}":{nm} (int a, int b) -> int { return ~$expr; };
        };

        i++;
    };

    // emit dispatch(int id, int a, int b) -> int
    // body is a switch with one generated case per op
    compiler.io.console.println("[comptime] generating dispatch...");

    emitflux { def dispatch(int id, int a, int b) -> int;  };

    // we need to emit the full function body as one emitflux,
    // so build the case list by emitting each case individually
    // inside a generated function shell

    // emit the switch shell open
    emitflux
    {
        def dispatch(int id, int a, int b) -> int
        {
            switch (id)
            {
    }#;

    // emit one case per op
    int j, jv;
    while (j < NUM_OPS)
    {
        nm = op_names[j];
        jv = j;

        emitflux
        {
                case (~$i"{}":{jv;}) { return ~$i"op_{}":{nm;} (a, b); }
        };

        j++;
    };

    // close the switch and function
    emitflux
    {
                default { return -1; };
           #};
       #};
    };

    // emit the op name and symbol tables as plain arrays
    emitflux
    {
        byte*[NUM_OPS] g_op_names = [g"add", g"sub", g"mul", g"div"],
                       g_op_syms  = [g"+",   g"-",   g"*",   g"/"];
    };

    int fingerprint = ct_fact(6);
    compiler.io.console.println(f"[comptime] fingerprint = {fingerprint}");

    emitflux
    {
        int g_fingerprint = ~$f"{fingerprint}";
    };

    compiler.io.console.println("[comptime] done.");
};

// -------------------------------------------------------------------
// Step 3: runtime
// -------------------------------------------------------------------

def usage(byte* prog) -> void
{
    println(f"usage: {prog} <op> <a> <b>");
    println(g"ops:");
    int i = 0;
    while (i < NUM_OPS)
    {
        println(f"  {g_op_names[i]}  ({g_op_syms[i]})");
        i++;
    };
    println(f"build fingerprint: {g_fingerprint}");
};

def find_op(byte* name, int len) -> int
{
    int i, j, match;
    byte* candidate;
    while (i < NUM_OPS)
    {
        candidate = g_op_names[i];
        j         = 0;
        match     = 1;

        while (j < len)
        {
            { match = 0; break; } if (name[j] != candidate[j]);
            j++;
        };

        { return i; } if (match == 1);
        i++;
    };
    return -1;
};

def main() -> int
{
    int demo = clamp(42, 0, 100);
    named_print(demo);

    byte* prog    = g"metademo";
    byte* op_name = g"div";
    int   op_len  = 3;
    int   a       = 21;
    int   b       = 3;

    int op_id = find_op(op_name, op_len);

    if (op_id < 0)
    {
        println(g"unknown op");
        usage(prog);
        return 1;
    };

    int result = dispatch(op_id, a, b);

    println(f"{a} {g_op_syms[op_id]} {b} = {result}");
    println(f"stored in '{$result}': {result}");

    return 0;
};

Templates
Templates in Flux are type substitution. No SFINAE, no concept maps, no enable_if, no multi-line where clauses. They apply to functions, structs, objects, and operator definitions, and the compiler infers template parameters at call sites so angle brackets stay out of everyday code:

def foo<T>(T x) -> T { return x; };

int z   = foo(3);     // T inferred as int
float y = foo(5.5f);  // T inferred as float

Where Flux’s template system goes beyond Rust or Zig is constraint sets — named, reusable relational expressions that describe not just properties of a single type but how a family of types may interact throughout a template body:

constraint NoNarrowing(A)
{
    A !`< A    // A must never be narrowed anywhere in this template body
};

def serialize<T: int, :{NoNarrowing}>(T x) -> byte
{
    return 5 + x;   // Compile error: narrowing T to byte violates NoNarrowing
};

!`< // This operator (no bit lower)

is verified by walking the instantiated function body — not checked against a declaration, but found by analysis of actual operations. The example errors because5 + xwithx: intreturned intobyte` is an implicit narrowing, and the compiler finds it. Circular multi-parameter expressions describe type geometry in a single line:

D !~= B & [A !@ A] !~= C !< D !-= A`

Values of type A cannot have their address taken. D must be incompatible with B and A. B and A must be incompatible with C. C and D cannot appear on either side of a narrowing. D cannot be used in signed operations with A. This is not “T must implement Trait.” It is a relational specification of how a family of types may and may not interact, verified by the compiler across the entire template body.

Safety You Compose, Not Safety You Survive
Rust’s safety guarantee is structural: if it compiles without unsafe, a well-defined set of memory errors cannot occur. The tradeoff is friction, annotation, and the fact that the borrow checker is a conservative approximation that rejects some correct programs.

Zig’s safety guarantee is operational: sanitizers catch issues at runtime in debug builds, and you have an allocator and defer, and the language is simple enough that you can reason about it carefully. There is no type-level enforcement beyond what you build by convention.

Flux adds contracts, which are named code blocks you attach to functions as part of their specification. A contract ends up inside the function body. It is a modifier on the function’s declaration that the compiler splices into the generated code. Pre-contracts go before the function body. Post-contracts go before each return:

contract NonZero(a, b)
{
    assert(a != 0, "a must be nonzero");
    assert(b != 0, "b must be nonzero");
};

contract ResultPositive(a, b)
{
    assert(a + b > 0, "result must be positive");
};

def add(int a, int b) -> int : NonZero(a, b)
{
    return a + b;
} : ResultPositive(a, b);

The contract transforms the function into:

def add(int a, int b) -> int
{
    assert(a != 0, "a must be nonzero");
    assert(b != 0, "b must be nonzero");
    assert(a + b > 0, "result must be positive");
    return a + b;
};

Contracts can go on operator overloads. If you define a custom addition operator for a BigInt type, you can attach a contract that verifies invariants on every call without that logic living inside the function itself:

operator (int L, BigInt R) [+] -> BigInt : NonZero(L, R)
{
    // Implementation
};

The contract runs on every dispatch to that overload. The verification is real. The overhead is proportional to what you assert, not to a global memory model.

Traits in Flux serve the same role as in Rust — enforcing interface compliance at compile time — but without the orphan rules, coherence requirements, or the separation between defining a trait and implementing it that makes Rust trait code fragile across crate boundaries. A trait is a list of prototypes an object must implement:

trait Drawable
{
    def draw() -> void;
};

Drawable object myObj
{
    def __init() -> this { return this; };
    def __exit() -> void {};
    def __expr() -> myObj* { return this; };
    def draw() -> void
    {
        // Must have a body; an empty implementation is a compile error
    };
};

Interfaces go further than traits by restricting which methods two objects may call on each other to an explicitly declared list. Calling any method not in the interface’s listed set — even a public one — is a compile error:

interface Stream(A: Readable, B: Writable)
{
    A : B { read(byte*,int)->int, write(byte*,int)->int, flush()->int };
    B : A { ack()->int };
};

object Pipe {} : Stream(this, Socket);

Once Pipe declares this interface, the compiler verifies at every Socket call site that the method being called is in the declared list. Socket does not need to know about the interface. The enforcement is on Pipe's use of Socket, not on Socket's definition. This is a different and often more practical model than Rust's, where coherence rules dictate what can be implemented where.

Deprecation is a first-class language feature rather than a compiler attribute or documentation convention:

deprecate test1::test2;

Referencing a deprecated namespace anywhere in the program is a compile error with a precise message showing the call site. You cannot accidentally leave uses of a deprecated API in a codebase. The compiler will not compile until they are removed.

A Data Model Built for Hardware
Rust’s type system thinks in structs, enums (which are really tagged unions), and references. It has u8, u16, u32, u64, and so on. If you need a 13-bit integer, you use a u16 and mask manually, or you reach for a proc macro crate like bitfield. The language does not have a concept of arbitrary-width integers as first-class types.

Zig has packed structs and a more explicit integer width system (u13, i7, etc.) that gets you closer. But the control over alignment, endianness, and the ability to chain type aliases is not there.

Flux has the data keyword, which creates arbitrary-width integer types as first-class language citizens:

signed data{13:16} as strange13;     // 13-bit signed, 16-bit aligned
unsigned data{3} as tiny;            // 3-bit unsigned, values 0-7
unsigned data{7:8} as aligned7;      // 7-bit with 8-bit alignment
unsigned data{5}[10] as 5b_array;    // Array of 5-bit values

The full specification is data{width : alignment : endianness}. Big-endian is the default. Little-endian is specified as the third parameter with 0:

data{16::0} as le16;   // Little-endian 16-bit
data{16}    as be16;   // Big-endian 16-bit (default)

Endian conversion in Flux is handled by assignment between types of different endianness — the compiler emits the byte swap. There is no byteswap intrinsic to remember to call. There is no htons/ntohs family. You assign a be16 to an le16 and the swap happens:

def network_to_host(be16 net_value) -> le16
{
    le16 x = net_value;   // Byte swap emitted automatically
    return x;
};

All math is performed in a single endianness internally. Mixed-endian arithmetic does not silently produce the wrong answer because there is no mixed-endian arithmetic — the conversion happens at assignment, not mid-expression.

You can also type-pun chains of data aliases:

unsigned data{16} as dbyte;
dbyte as xbyte;
xbyte as ybyte;
ybyte as zbyte zbx = 0xFF;

Each alias is a distinct type for the compiler’s purposes. endianof, alignof, sizeof, and typeof are built-in operators that return properties of any type:

sizeof(strange13);    // 13 (bits)
alignof(strange13);   // 16
typeof(strange13);    // "signed data{13:16}"
endianof(strange13);  // 1 (big-endian)

This is the type system that networking code, cryptography implementations, hardware register maps, and binary protocol parsers actually need. You do not reach for a proc macro crate or maintain a packed_struct wrapper. You write the type you mean.

The Bit Manipulation Story
One of the most tedious aspects of systems programming is bit manipulation. Extracting a field from a packed register. Replacing a range of bits in place. Converting between array representations and integer representations. Every language leaves you writing the same masking and shifting patterns over and over.

Flux has the bit-slice operator which extracts a range of bits from any integer-width value and returns it as a value of the appropriate width:

u32 packed = 0x12345678;
u32 nibble0 = packed[0``3];    // Bits 0-3:   0x8
u32 nibble3 = packed[12``15];  // Bits 12-15: 0x5
u32 byte1   = packed[8``15];   // Bits 8-15:  0x56

Assignment into a bit slice replaces just that range in place, leaving every other bit untouched:

u32 packed = 0x12345678;
packed[24``31] = 0xFF;
// packed == 0x123456FF

This eliminates entire categories of (value & mask) >> shift boilerplate. The start and end indices must be compile-time constants, so the compiler can verify correctness and generate the right mask in one step.

Array-to-integer packing takes this further. Casting a fixed-size array to an integer type packs the array element-by-element into the integer, with element 0 occupying the most significant bits. This is defined behavior with a consistent convention, not implementation-defined. The consequence is that multi-byte big-endian operations that take 16 lines in C can take one in Flux:

len_block[0]  = (byte)((aad_bits >> 56) & 0xFF);
len_block[1]  = (byte)((aad_bits >> 48) & 0xFF);
len_block[2]  = (byte)((aad_bits >> 40) & 0xFF);
len_block[3]  = (byte)((aad_bits >> 32) & 0xFF);
len_block[4]  = (byte)((aad_bits >> 24) & 0xFF);
len_block[5]  = (byte)((aad_bits >> 16) & 0xFF);
len_block[6]  = (byte)((aad_bits >>  8) & 0xFF);
len_block[7]  = (byte)( aad_bits        & 0xFF);

Flux:

len_block[0..7] = (byte[8])(u64)aad_bits;

The array comprehension syntax makes bulk initialization similarly expressive:

int[10] squares = [x ^ 2 for (int x in 1..10)];
int[20] evens   = [x     for (int x in 1..20) if (x % 2 == 0)];

Python-style and C-style comprehension both work. You can also comprehend over dynamic collections:

Array[] filtered = [x.name for (Array x in oldArr) if (x.name.len() > 5)];

Structs, Objects, and the Separation Between Data and Behavior
C++ conflated data and behavior in classes, giving you a type that could be both a plain data container and a method-laden object. This was convenient but blurred the distinction between things that are just memory layouts and things that are executable. Rust’s structs and impl blocks separate layout from behavior but do not enforce that one particular kind of type is only data.

Flux makes the separation explicit and enforced at the language level. Structs are data only:

struct Header
{
    data{16} sig;
    data{32} filesize, reserved, dataoffset;
};

Placing any executable statement — a for loop, an if block, a try/catch, a function definition — inside a struct is a compile error. Structs cannot contain functions or objects. They can contain pointers, including function pointers. They are tightly packed with no padding unless alignment is specified in the type. This is not something you configure with #[repr(packed)] or a pragma. It is the default and the only layout.

Struct composition is done directly in the definition without OOP inheritance ceremony:

struct BMP : Header, InfoHeader
{
    // Additional BMP fields
} : ExtraData;

This prepends and appends fields from the named structs. No vtables. No runtime polymorphism. Just “the layout of BMP includes these fields from these structs in this order.”

Objects are the executable counterpart. They can contain methods, use this, and have lifecycle management through required methods:

object SomeObj
{
    int val;

    def __init(int x) -> this
    {
        this.val = x;
        return this;
    };

    def __exit() -> void {};

    def __expr() -> int { return this.val; };
};

__init is the constructor, called on instantiation. __exit is the destructor, called manually or via defer. __expr is the expression context method — when an object instance appears in an expression context, the compiler calls this and uses its return value. So println(sobj) becomes println(sobj.__expr()) automatically.

If __init takes exactly one parameter, you can instantiate with assignment syntax:

SomeObj sobj = 5;    // Equivalent to SomeObj sobj(5);

Object inheritance in Flux is designed to eliminate the diamond problem rather than work around it. A child object inherits all non-private, non-mandatory members from its parents. If two parents have a method with matching signatures but different implementations, the compiler errors. The child does not inherit mandatory methods (__init, __expr, __exit) and must define its own. Multiple inheritance is expressed as object C : A, B. The !+ modifier marks a method as non-overridable, and attempting to override it in a child is a compile error.

The separation between struct and object also matters for templates: struct template parameters cannot be of object type, because objects are not pure data. The compiler enforces this. You cannot accidentally instantiate a struct template with a type that carries behavior.

Error Handling Without a Return Type Tax
Rust’s error handling uses the Result<T, E> type and the ? propagation operator. It is clean, compositional, and enforced: you cannot accidentally ignore an error because the return value is a Result that you must handle or propagate explicitly. The cost is that every function in a call chain that can fail must have its return type annotated with Result, and the error type must propagate consistently or be converted.

Zig uses explicit error unions (!T) and try for propagation. The error set is part of the type and can be inferred. This is cleaner than Rust in some ways — the error types are values not trait objects — but it still means annotating every function in the chain.

Flux uses try/throw/catch with typed catches that dispatch on the thrown type. This is structurally similar to C++ exceptions but without the hidden stack unwinding cost — the design is explicit call-site dispatch rather than a global unwind table:

object ERR
{
    byte* message;
    def __init(byte* m) -> this { this.message = m; return this; };
    def __exit() -> void {};
    def __expr() -> byte* { return this.message; };
};

def myErr(int code) -> void
{
    switch (code)
    {
        case (0)
        {
            ERR e("Custom error\0");
            throw(e);
        }
        default
        {
            throw("Default error\0");
        };
    };
};

def main() -> int
{
    try
    {
        myErr(0);
    }
    catch (ERR e)        // Typed catch: dispatches on ERR object
    {
        byte* msg = e.message;
    }
    catch (byte* s)      // Typed catch: dispatches on raw string
    {
    }
    catch (auto x)       // Catch-all
    {
    };
    return 0;
};

Catches dispatch in order on the thrown type. auto is the catch-all. assert integrates with the try/catch system: inside a try block, a failed assert throws the assertion message as a string rather than writing to stderr, so you can catch assertion failures with the same mechanism as thrown errors.

The practical difference from Rust’s model is that functions in the middle of a call chain do not need to annotate their return types with a result type to propagate errors. A function that might throw simply throws. The catch happens where you want to handle it. For many patterns — particularly in systems code where you want to catch errors at a high level and log or recover — this is less boilerplate than threading Result through every layer.

The Operator System
Rust allows operator overloading through trait implementations. The set of overloadable operators is fixed. You implement std::ops::Add for your type and + dispatches to it. This is clean but limited to the existing operator set, and implementing it requires understanding the trait system and lifetime annotations on the return type.

Zig has no operator overloading.

Flux has a complete operator system that allows both overloading existing operators and defining entirely new ones:

// New operator
operator (int L, int R) [+++] -> int
{
    return ++L + ++R;
};

int result = a +++ b;   // Dispatches to the custom operator

// Identifier-based operator
operator (int L, int R) [NOPOR] -> bool
{
    return !L | !R;
};

bool check = a NOPOR b;

Overloading built-in operators follows two rules: one parameter must not be a built-in type (so you cannot silently override integer addition), and the overload’s precedence and associativity cannot be changed from the built-in symbol’s. These rules prevent the most common overloading abuses while leaving the useful cases open.

Custom operators also accept contracts:

operator (int L, BigInt R) [+] -> BigInt : ValidOperands(L, R)
{
    // Implementation
};

Every dispatch to this overload runs ValidOperands first. The contract is part of the operator's specification, not its implementation.

Templated operators instantiate lazily on first use with concrete types:

operator<T> (T L, T R) [+] -> T
{
    // Generic implementation
};

Each time this appears in code with a new concrete pair of types, a new overload is generated for that pair.

Soon, Flux will allow you to create prefix and postfix operators, not just infix, as well as specify precedence.

Type Functions and the Method Call Syntax Problem
Rust puts methods on types through impl blocks, which are separate from the type definition and can appear anywhere. This means the method set of a type is open — anyone can add methods to any type in any file. Zig has no method syntax; you call TypeName.function(value, args) with the first parameter being the receiver.

Flux has type functions, which extend any type with dot-call syntax without the overhead of object definitions or the open-world problem of impl blocks:

byte*.reverse() -> byte*
{
    // _ is the receiver, equivalent to `this`
    // implementation...
};

println("world".reverse());   // Calls the above

You can do this for built-in types, struct types, and pointer types. The receiver is _ inside the function. You can also use "" as shorthand for the string type:

"".add_world() -> ""
{
    return _ + ", World!";
};

byte* greeting = "Hello".add_world();  // "Hello, World!"

Literal modifier functions let you define behavior that attaches to literal suffixes:

0.my_int_func() -> int   // Attaches to integer literals: 55.my_int_func()
{
    return _;
};
Tied types can have type functions too:

~byte*.consume() -> ~byte*
{
    return _[0] - 11;
};

This means the ownership semantics propagate through type function calls the way you would expect: calling a type function on a tied value moves the tied value into the function’s scope.

To disallow a type from having functions, you must create a primitive with data! like so:

#import <standard.fx>;

using standard::io::console;

data!{32} as u32i;

u32i.foo() -> u32i { return 0u; };

def main() -> int
{
    return 0;
};

Control Flow That Says What It Means
Rust’s control flow is mostly conventional C with match as the flagship addition. Zig's control flow is simpler than C's in some ways — no implicit fallthrough in switch, for example — but does not add much beyond the explicit.

Flux makes deliberate decisions about control flow that make code more readable and less error-prone.

elif is a first-class keyword rather than else if, following Python's lead and reducing a common visual indentation problem:

if (x > 0)      { doThis(); }
elif (x < 0)    { doThat(); }
else            { doDefault(); };

Switch statements do not fall through between cases. Each case is its own block. Exiting a switch uses break switch; rather than bare break, so when a switch is inside a loop, a break unambiguously exits the loop rather than the switch:

for (int i = 0; i < n; i++)
{
    switch (values[i])
    {
        case (0)
        {
            // handle zero
            break switch;   // Exits the switch
        }
        case (1)
        {
            if (done) { break; };   // Exits the for loop
        }
        default
        {
            continue;   // next iteration of the for loop
        };
    };
};

There is no ambiguity. break switch means the switch. break means the nearest enclosing loop. They are different things with different syntax.

The in keyword works as both a loop iterator and a membership test in any expression context:

int[5] arr = [1, 2, 3, 4, 5];
if (3 in arr) { found(); };

int[2] pair = [3, 4];
if (pair in arr) { contiguous_match(); };

byte* s = "Hello World";
if ("World" in s) { substring_found(); };

A single operator handles value membership, sub-sequence search, and substring search depending on the types involved. The intent is readable at the call site without needing a method name to explain what is happening.

singinit variables initialize exactly once across all calls to a function, providing static-local-like semantics:

def counter() -> void
{
    singinit int x;   // x initializes to 0 on first call, retains value on subsequent calls
    x += 1;
    print(x);
};

Strict tail recursion with <~ guarantees zero stack growth for recursive functions and is a compile-time enforcement rather than an optimizer hint:

def recurse() <~ void
{
    // Function always returns to itself
    // musttail is emitted; stack frame cannot grow
};

If you write code in a <~ function that would prevent tail-call optimization, the compiler errors. You can break out of strict recursion with escape to jump to a different function, which is the only way to exit a <~ function to a non-self target, used like escape other_func();.

Memory Management Without the Ceremony
Rust’s memory management comes from the borrow checker plus smart pointers like Box, Rc, and Arc. Knowing when to use which, and how to structure your data to avoid reference cycles in Rc, is a substantial part of the Rust learning curve. The stack vs. heap distinction is mostly implicit — let x = 5 is stack, Box::new(5) is heap.

Zig is explicit about everything: you call allocator.alloc(), you call allocator.free(), and you use defer to ensure cleanup. The allocator is a parameter you thread through your code. This is completely honest but adds boilerplate.

Flux makes the distinction explicit with syntax rather than with a separate type hierarchy:

int x = 5;        // Stack allocated
heap int y = 5;   // Heap allocated; y is a pointer

Deallocation uses the void cast, which also works on stack variables (zeroing them and invalidating the reference):

(void)y; // Frees the heap allocation; y is no longer valid

The defer keyword handles cleanup in the same LIFO order as Zig, but in Flux defer can be a block:

heap int* buffer = allocate_thing();
defer
{
    cleanup_side_effects();
    (void)buffer;   // Freed last, after side effects are cleaned up
};
// Work with buffer here; cleanup is guaranteed on any return path

Deferred statements execute after post-contract code and immediately before the function returns, in reverse declaration order. This makes resource cleanup predictable and composable without an RAII wrapper type.

Performing Inline Assembly
All three languages support inline assembly. In Rust it is asm! with a domain-specific argument syntax. In Zig it is @asm with explicit I/O binding. Both work. Neither is especially readable.

Flux uses AT&T-style assembly in an explicit block with architecture guards and standard constraint syntax:

def _exchange64(i64* ptr, i64 value, i64* out) -> void
{
    #ifdef __ARCH_X86_64__
    volatile asm
    {
        movq $0, %rsi
        movq $2, %rdi
        movq $1, %rax
        xchgq %rax, (%rsi)
        movq %rax, (%rdi)
    } : : "r"(ptr), "r"(value), "r"(out) : "rax", "rsi", "rdi", "memory";
    #endif;
    #ifdef __ARCH_ARM64__
    volatile asm
    {
    .retry_xchg64:
        ldaxr x0, [$0]
        stlxr w3, x1, [$0]
        cbnz  w3, .retry_xchg64
        str   x0, [$2]
    } : : "r"(ptr), "r"(value), "r"(out) : "x0", "w3", "memory";
    #endif;
};

The pattern outputs : inputs : clobbers follows GCC's inline assembly convention, which means programmers who already know how to write inline assembly in C can write it in Flux without learning a new constraint language. The volatile tag tells the compiler to not touch the block under any circumstances. The #ifdef __ARCH_*__ guards are preprocessor directives that let you write one function with platform-specific implementations, all in one place.

This matters for systems code in a way that higher-level languages can wave away. Writing a compare-and-swap, a spinlock, or a hardware I/O operation requires inline assembly in most cases. Having a readable, familiar interface to it — rather than a domain-specific macro language bolted on top — reduces the chance of getting the constraints wrong.

The Tooling Picture
Flux compiles to native code via LLVM, which means it has access to the same optimization passes and target backend support as Rust and Zig. The fxc.py compiler frontend handles lexing, parsing, type checking, and LLVM IR generation. A VM interpreter (fvm.py) exists for development and debugging, allowing programs to be run and traced without a full compile-link cycle.

The package manager fpm handles dependencies with local registry storage. Libraries compile to .so on Linux and .dll on Windows with the same source-level export syntax:

export
{
    def !!my_function() -> void {};
};

The !! prefix suppresses name mangling, making the export link-compatible with C. You can call any Flux library from C and vice versa using the same extern declaration mechanism that declares external functions. Alternatively you can declare the calling convention as cdecl:

export
{
    cdecl my_function() -> void {};
};

For interoperating with existing C codebases, a translation tool called cft parses C headers and source files using libclang and emits Flux equivalents. This handles the majority of mechanical translation: function prototypes become extern declarations, typedef pointer chains become Flux type aliases, struct definitions become Flux structs, switch statements emit break switch correctly, and raw pointer arithmetic is preserved for manual review. The tool is not a perfect translator — macro-heavy C code requires manual intervention — but for coreutils-scale C codebases it produces a readable starting point.

What Flux Is Not Claiming
Flux isn’t claiming to be formally verified. It does not generate proofs. It does not use linear types in the sense that Idris or ATS do. The tie operator is a practical ownership model, not a full affine type system.

Flux is not claiming that its error handling is better than Rust’s Result in every context. For a large library where you want callers to be statically forced to handle every failure case, typed returns are a better fit. The try/throw/catch model is better for systems code where you want to catch errors at a high level rather than threading a result type through twenty call frames.

Flux is not claiming to be Rust’s replacement in organizations where the borrow checker’s guarantees are worth the friction. Those organizations exist and their choice is justified.

What Flux is claiming is that there is a large and underserved space between “fight the borrow checker” and “rely entirely on discipline.” A space where a programmer who knows what they are doing wants real safety tools — ownership on specific types, contracts on functions, trait enforcement on interfaces, compile-time constraint verification on templates — without a global memory model they have to opt into for their entire program. A space where the type system is expressive enough to describe a 13-bit signed integer with 16-bit alignment and big-endian byte order as a first-class type, not an abstraction on top of a u16. A space where bit manipulation is readable, control flow says what it means, and the language assumes you are a professional.

That is the space Flux is designed for, and it’s a space both Rust and Zig left open.

Flux is an actively developed systems programming language. Source code, the full language specification, and the community Discord are available at the Flux GitHub repository. Try out the online compiler!

Algebraic Types? Type Geometry? How Far Can a Language Be Pushed? Compile-Time Execution, Relational Interfaces, and More

Karac Thweatt — Fri, 12 Jun 2026 23:34:14 +0000

Flux is a compiled, stack-first, general-purpose language with a refreshingly direct philosophy: you own your memory, you write your intent, and the compiler takes you seriously. If you haven't looked at it in a while - or at all - now is a great time to pay attention.
Over the past development cycle, Flux has gained several major features that collectively shift it from a capable low-level language into something with serious expressive power. Let's walk through what's new.

Compile-Time Execution with comptime This is the headline feature. Flux can now execute Flux at compile time, powered by a dedicated VM built specifically for this purpose. The same VM will also power the upcoming REPL. The model is simple: wrap any code in a comptime block and it runs during the compilation pass, before any runtime code is generated.

#import <standard.fx>;

comptime
{
    def foo() -> void
    {
        compiler.io.console.print("Hello from compile time!\n");
    };

    foo();
};

def main() -> int
{
    return 0;
};

When you compile this, Hello from compile time! prints in the middle of the compiler's own output - during the AST codegen pass. It's not a preprocessor macro, it's not a constexpr evaluation hack. It's real Flux code running in a VM while your program is being compiled.
You can split comptime work across multiple blocks, and they share scope:

comptime
{
    def greet(int n) -> void
    {
        compiler.io.console.print(f"Step {n} complete\n");
    };
};

comptime
{
    greet(1);
    greet(2);
};

What's Already Supported
A large portion of the Flux keyword set is available at comptime right now. The full list of what's live:
and, as, bool, byte, case, char, constraint, data, def, default, do, double, elif, else, emitflux, enum, false, float, for, goto, if, int, is, label, long, not, or, return, signed, sizeof, struct, switch, true, uint, ulong, union, unsigned, while
Control flow, arithmetic, structs, enums, unions, loops, conditionals - the core of the language is already there. Standard I/O and file I/O work. Networking is deferred to a future update.
A few keywords like lext are explicitly deferred for the bootstrap phase. The rest are being filled in progressively.
What This Unlocks
Compile-time execution is the foundation for build-time code generation, compile-time validation, configuration baking, and eventually a full macro system that operates on real Flux ASTs rather than text substitution. The comptime VM running the same semantics as the runtime means there's no separate "template language" to learn - it's just Flux.

Algebraic Types - Type Algebra with constraint Flux has always had templates. Now it has relational constraints on templates, which is a meaningful step up. The constraint keyword lets you define named constraint sets that express algebraic relationships between type parameters. These constraints are then attached to template functions to restrict what combinations of types are valid at instantiation.

constraint SafeArith(A, B)
{
    A ~= B,
    A !`< A
};

def add<T: int, U: int, :{SafeArith}>(T x, U y) -> T
{
    return x + y;
};

The Operators
Operator Meaning ~= A and B must be compatible (same pointer depth, matching bit width) !~= A and B must be incompatible - enforces they remain distinct !@ Address-of (@) is forbidden on values of this type within the template body !< No truncation - type cannot appear in a narrowing context !<= No truncation between these two specific types !> No widening !>= No widening between these two specific types !-= A and B cannot participate in unsigned arithmetic together
Constraints can be written inline directly on the template parameter:

def foo<T: int, :{T !`< T}>(T x) -> void
{
    // T can never be truncated anywhere in this function
};

Or chained - the right-hand side of one relation becomes the left-hand side of the next:

constraint Chain(A, B, C)
{
    A ~= B !~= C !`< C
};

That reads as three independent relations:

A ~= B, B !~= C, C !< C`

You can also merge constraint sets:
constraint Combined = MyCS1 + MyCS2;
The merge checks for contradictions at definition time - you can't combine ~= and !~= on the same operand pair.
Why This Matters
Most languages give you bounded generics at best. Flux's type algebra lets you express things like "these two type parameters must not be able to truncate into each other," or "this type can never have its address taken inside this template." These constraints fire at instantiation time with precise error messages, not vague template errors deep in a call stack.

Interfaces - Typed, Named, and Enforced Flux already had traits (behavioral contracts on objects). Interfaces build on top of them to define how two objects communicate with each other.

trait Readable
{
    def read(byte*,int)->int,
        write(byte*,int)->int,
        flush()->int;
};

trait Writable
{
    def ack()->int;
};

interface Stream(A: Readable, B: Writable)
{
    A : B
    {
        read(byte*,int)->int,
        write(byte*,int)->int,
        flush()->int
    };

    B : A
    {
        ack()->int
    };
};

The interface is generic - A and B are type parameters constrained by traits. The body defines which methods each side is permitted to call on the other.
You attach it to an object at the definition site:

object Pipe
{
    ///...///
} : Stream(this, Socket);

Once attached, any method call between Pipe and Socket that isn't explicitly listed in the interface is a compile-time error - even if the method is public. The interface is the contract and it is enforced statically.
If Pipe tries to use a Socket that doesn't satisfy Writable, the compiler catches it. The Socket side doesn't need to declare the interface at all - only Pipe owns it.
This is a principled answer to the "I need to formalize how these two things talk to each other" problem without runtime overhead and without ceremony on the other side of the connection.

Object Inheritance Flux now supports object inheritance, including multiple inheritance, with rules designed to eliminate the diamond problem entirely - the compiler simply won't let it exist.

object A
{
    int a1, a2, a3;
    def __init() -> this { return this; };
    def __exit() -> void { (void)this; };
};

object B
{
    int b1, b2, b3;
    def __init() -> this { return this; };
    def __exit() -> void { (void)this; };
};

object C : A, B
{
    int c1, c2, c3;
    def __init() -> this { return this; };
    def __exit() -> void { (void)this; };
};

The rules are clear and predictable:
Mandatory methods (__init, __expr, __exit) are not inherited - the child always defines its own lifecycle.
If two parents define a function with matching signatures but different implementations, it's a compile error. No silent resolution.
Private members are not inherited unless the parent explicitly grants access via private : ChildName.
A child member that already exists in the child takes precedence - the parent's version is not inherited.

You can use !+ on a parent method to mark it non-overridable:

object B
{
    !+ def foo() -> void {};
};

object C : B
{
    + def foo() -> void {};  // Compiler error - B said no override
};

The diamond problem is eliminated structurally. The rules ensure that any ambiguity in the inheritance tree is always an error, never a silent wrong answer.

Type Functions - Methods on Any Type Type functions let you define methods directly on any type - including built-in primitives - that are called using dot notation.

byte.clamp(byte lo, byte hi) -> byte
{
    if (_ < lo) { return lo; };
    if (_ > hi) { return hi; };
    return _;
};

byte value = 200;
byte result = value.clamp(0, 127);

The _ identifier is the implicit receiver inside the type function body. It cannot be redeclared. The receiver can be written as the type name itself (byte, int, float) or as the null literal of that type (false for bool, 0l for long, 0d for double).
For named struct types, use the struct name directly:

struct Vec2
{
    float x, y;
};

Vec2.length() -> float
{
    return sqrt(_.x * _.x + _.y * _.y);
};

Vec2 v {x = 3.0, y = 4.0};
float len = v.length();  // 5.0

This gives you the ergonomics of method syntax on data you define - including types you don't own. It's not monkey-patching; it compiles down to a normal function call. The dot notation is purely syntactic.

Try It Online Flux now has an online IDE at https://fluxspl.org/ide. No toolchain setup. No build configuration. Write Flux, run Flux, see the output. It's the fastest way to get your hands on the language and test out the features above.

The Bigger Picture
What's interesting about this release cluster is that the features reinforce each other. Comptime execution gives you a way to validate and generate things before the binary exists. Algebraic types let you put mathematical guarantees on your generic code. Interfaces formalize object collaboration without runtime overhead. Inheritance gives you composable object hierarchies with clear, non-surprising rules. Type functions make the results of all of that genuinely pleasant to work with.
Flux has always been a language that takes a position - stack first, explicit semantics, no hidden costs. These additions keep that philosophy intact while expanding what you can express. Worth watching.

Flux source, documentation, and the compiler are available on GitHub. Join the Flux Discord if you want to follow development or ask questions directly.

Flux: The New Programming Language Built for Tomorrow’s CPUs

Karac Thweatt — Wed, 13 May 2026 20:04:27 +0000

As we enter an era of massive hardware innovation, the design of programming languages must evolve to keep pace with modern advancements. Flux is more than just a language, it’s the embodiment of a new paradigm in systems programming, purpose-built to leverage the architectural trajectory of modern CPUs, particularly the advent of massive cache hierarchies.

Designed with insights into how hardware is evolving, Flux stands out as the only systems programming language that fully embraces stack-by-default memory allocation, making it the fastest and most efficient language for modern performance-critical applications. Here’s why Flux is not just relevant today, but also future-proof for the next generation of CPUs.

The Hardware Shift: CPUs Are Scaling Cache, Not Clock Speed

For decades, performance gains in CPUs came largely from increasing clock speeds. However, as heat and power efficiency limits closed that path, CPU designers turned to:

Multi-core processing for parallelism
Out-of-order execution for smarter instruction handling, and
Massive on-chip caches to reduce memory latency

Recent CPUs, such as AMD’s models with 448MB of total cache, reflect this shift towards leveraging low-latency, high-bandwidth cache hierarchies. These caches are the new performance battleground, capable of delivering data at speeds 10–20x faster than main memory (RAM).

However, most programming languages have not adapted to this evolution:

Heap-first architectures lead to fragmented, unpredictable memory patterns that fail to exploit the benefits of caches.
Legacy languages like C and C++ require manual and deliberate stack management, creating unnecessary friction for developers aiming to optimize their performance
Even systems languages like Rust pay penalties due to memory safety guarantees and reliance on the heap for ownership-validation mechanisms.

Flux changes all of this.

The Flux Advantage: Stack-by-Default Design

Flux is the only language built from the ground up with stack allocation as the default behavior.

Unlike other systems languages that encourage or allow heap-dependence unless explicitly overridden, Flux ensures that everything is allocated on the stack by default, including pointers, unless otherwise specified by the programmer.

Why Stack-First Optimizations Matter:

Faster Memory Access

Memory allocated on the stack stays cache-resident or close to it, making it up to 20x faster than heap memory.
Heap memory, by contrast, is dynamically allocated and often ends up scattered across random regions in main memory, slowing access.

Cache-Friendly by Design:

Stack allocation leverages spatial and temporal locality — data is laid out in a predictable, linear fashion, making it easy for modern CPUs to prefetch and cache efficiently.

Zero Fragmentation:

The stack eliminates the challenges of heap fragmentation, ensuring predictable memory management. This simplifies programs while improving both performance and reliability.

Minimal Runtime Overhead:

Stack management has virtually zero overhead since allocation and deallocation follow straightforward linear patterns. Heap management requires algorithms with non-trivial costs to handle allocation, garbage collection, or reference counting.

Competitive Edge: Why Flux Outperforms C, Rust, and Others

With its stack-first philosophy, Flux inherently delivers predictable performance gains, even against heavyweight competitors.

Flux vs C:

C requires explicit management: While C allows stack allocation, developers must manually ensure variables remain on the stack. Flux removes this cognitive overhead by making the stack the default.
Flux also avoids C’s reliance on the heap for constructs like dynamic pointers — critical in systems programming.

Flux vs Rust:

Rust’s borrow checker introduces runtime overhead and restricts developers to ownership-based memory models, often forcing heap usage for safety.
Flux trusts the programmer while offering opt-in ownership without unnecessary restrictions, enabling stack-first patterns that outperform Rust in cache-bound workloads.

Flux vs Python/Go:

Unlike managed languages (Python, Go), which abstract memory management entirely with heap and garbage collection, Flux gives direct control over allocation allowing it to operate in low-latency and resource-constrained environments.

Why Flux Is Future-Proof for the New CPU Era

The trend of massive CPU caches and increasingly complex memory hierarchies solidifies Flux’s position as the language of the future. Here’s why:

Made for Modern Hardware:

Modern CPUs are optimized for patterns of locality, and Flux’s stack-first design takes advantage of this by ensuring that data resides in low-latency, high-speed caches.

Scalable Performance:

As CPUs integrate even larger caches, the performance gap between stack and heap usage will only grow. Flux’s focus on stack allocation guarantees that it remains the fastest option on high-end hardware.

Low Overhead for High Throughput:

Massive parallel systems with dozens or hundreds of cores require predictable memory behavior for lock-free, low-contention programming. Flux’s stack philosophy ensures that even in heavily threaded environments, memory contention is minimized.

Ideal for Real-Time and Embedded Systems:

With its stack-first design, Flux is ready for embedded systems, IoT, edge computing, and game engines — domains where deterministic performance, low latency, and efficient use of limited resources are critical.

Aligned with Green Computing:

Efficient cache usage not only improves speeds but also reduces energy consumption, making Flux a natural fit for energy-efficient software development in a resource-conscious world.

The Future is Flux

Programming languages often lag behind hardware advancements, but Flux flips the equation. By aligning itself with the trajectory of cache-optimized, high-core-count CPUs, Flux redefines systems programming for the modern and future eras of computing.

Whether you’re optimizing embedded devices, building network protocols, developing game engines, or working on memory-intensive applications, Flux delivers unmatched performance with its stack-first design philosophy. It is not just a language for today — it is the future of systems programming.

Where Can I Get Flux?

Flux is on GitHub at https://github.com/kvthweatt/Flux

[Boost]

Karac Thweatt — Mon, 27 Apr 2026 21:23:35 +0000

Karac Thweatt

Apr 27

Flux - the new programming language is built for speed, easy to read, and familiar.

#programming #language #compilers #flux

6 min read

Flux - the new programming language is built for speed, easy to read, and familiar.

Karac Thweatt — Mon, 27 Apr 2026 21:20:55 +0000

I've been working on Flux - my new compiled, general-purpose systems programming language - and wanted to write up what it looks like today. This isn't a roadmap post or a vision doc, just a walkthrough of the language as it exists right now. Source files use the .fx extension, the compiler targets LLVM, and the language is nearing bootstrap.

First things first. Flux is not C, nor a C derivative / wrapper.

Let's start simple and build up from there.

Hello, World

#import "standard.fx";

using standard::io::console;

def main() -> int
{
    print("Hello, World!\n");
    return 0;
};

A few things to notice immediately: def is the function keyword, -> declares the return type, and the closing brace of a compound statement gets a semicolon - compound statements are terminated just like any other statement in Flux. It's consistent everywhere once you internalize it.

#import is textual - it splices the file contents at the import site. Multiple imports are processed left to right:

#import "standard.fx";
#import "mylib.fx", "foobar.fx";

The using declaration brings a namespace into scope. Namespaces use :: for access, and duplicate namespace definitions merge rather than conflict - a library can spread a namespace across multiple files and it behaves as one namespace at the use site.

Variables and Primitives

Flux has the types you'd expect for systems work:

bool, byte, int, uint, long, ulong, float, double, char, void

And one you might not: data. More on that shortly.

Variables are stack-allocated by default. Heap allocation requires the heap keyword - there's no implicit dynamic allocation anywhere.

int x = 5;
uint y = 300u;
float pi = 3.14159;
bool flag = true;

heap string s = "some data";
(void)s;   // explicit cleanup

Multiple declarations can be comma-chained:

int x = 10,
    y = 20,
    z = y - x; // declared in order, so this works

void as a value equals 0 equals false. You can use it directly in expressions and comparisons, and it serves as the null value for pointers.

Functions

Functions live at module, namespace, or object scope - no nested function definitions.

def myAdd(int x, int y) -> int
{
    return x + y;
};

Overloading works on type signature:

def myAdd(float x, float y) -> float
{
    return x + y;
};

Prototypes (forward declarations) don't require parameter names, only types:

def myAdd(int, int) -> int,
    myAdd(float, float) -> float;

def is fastcall by default. Other calling conventions are first-class keywords like stdcall, cdecl, vectorcall, and thiscall.

Control Flow

Standard if/elif/else, for, while, do/while, and switch - all terminated with semicolons. switch only puts the semicolon on the default block. try/catch only puts it on the last catch.

for (int i = 0; i < 10; i++)
{
    if (i % 2 == 0) { continue; };
    print(f"{i}");
};

Ternary works as expected:

int z = x < y ? y : 0;

Flux also has a null-coalesce operator ?? and a conditional assign ?=:

int z = y ?? 0;    // z = y if y is non-null, else 0
x ?= 50;           // assign 50 only if x is currently null/zero

Structs

Structs are always packed - no compiler-inserted padding. You control alignment by choosing your types. They're non-executable: no functions, no objects, just data.

struct xyzStruct
{
    int x, y, z;
};

xyzStruct v {x = 1, y = 2, z = 3};
print(v.x);

Structs can contain other structs, support composition (prepend/append another struct's fields), and can be templated:

struct Pair<A, B>
{
    A first;
    B second;
};

Template arguments are inferred at the call site.

Objects

Objects are executable types with constructors, destructors, and methods. this is always implicit - never a parameter.

object Counter
{
    int val;

    def __init(int start) -> this
    {
        this.val = start;
        return this;
    };

    def __exit() -> void {};

    def increment() -> void
    {
        this.val++;
    };
};

Counter c = 0;       // sugar for Counter c(0);
c.increment();
print(c.val);

Single-parameter __init allows the assignment-style instantiation shown above.

defer runs cleanup in LIFO order, immediately before the function returns:

Counter c = 0;
defer c.__exit();
// ... c is cleaned up automatically at return

Traits enforce structural contracts at compile time:

trait Drawable
{
    def draw() -> void;
};

Drawable object Sprite
{
    def draw() -> void
    {
        // must not be empty
        return void;
    };
};

If a Drawable object doesn't implement draw(), compilation fails.

Error Handling

throw accepts any type. catch matches by type, with auto as the catch-all:

def risky(int mode) -> void
{
    if (mode == 1) { throw(ErrorA(100)); }
    elif (mode == 2) { throw(ErrorB("failed")); }
    else { throw("generic"); };
};

try
{
    risky(2);
}
catch (ErrorA e) { print(f"code: {e.code}"); }
catch (ErrorB e) { print(f"msg: {e.message}"); }
catch (string s) { print(s); }
catch (auto x)   { print("unknown"); };

Memory and Pointers

Heap allocation goes through fmalloc and ffree directly:

u64 p = fmalloc(sz);
if (!(@)p) { ok = false; break; };
total_bytes += (i64)sz;
ffree(p);

@ is address-of. (@) is an address cast - converts an integer value to a pointer. ! applied to a pointer emits a null check. There's also a postfix not-null operator !?:

if (ptr!?) { /* ptr is non-null */ };

Pointer arithmetic, casting, and raw dereferencing all work as you'd expect:

byte* bp = (byte*)@addr;
int val = *some_ptr;

The `data` Type and Bit-Level Work

data{N} declares N-bit raw storage, unsigned by default. You can apply signed and create type aliases with as:

signed data{32} as fixed16_16;

def to_fixed(float value) -> fixed16_16
{
    return (fixed16_16)(value * 65536.0);
};

def fixed_mul(fixed16_16 a, fixed16_16 b) -> fixed16_16
{
    i64 temp = ((i64)a * (i64)b) >> 16;
    return (fixed16_16)temp;
};

Flux also has endian-aware width types as first-class aliases: nybble, be16, be32, be64, le16, le32, and so on. Network and binary protocol structs look like this:

struct IPHeader
{
    nybble version, ihl;
    byte tos;
    be16 total_length, identification, flags_offset;
    byte ttl, protocol;
    be16 checksum;
    be32 src_addr, dst_addr;
};

def parse_ip(byte* packet) -> IPHeader
{
    IPHeader* header = (IPHeader*)packet;
    return *header;
};

def format_ip(be32 addr) -> string
{
    byte* bp = (byte*)@addr;
    return f"{bp[0]}.{bp[1]}.{bp[2]}.{bp[3]}";
};

Operators

Flux separates logical and bitwise operators syntactically. Logical: &, |, ^^ (XOR), !& (NAND), !| (NOR). Bitwise versions are prefixed with a backtick: `&, `|, `^^, `!.

Shifts: <<, >>.
Bit slice (extracts a range of bits):

a[x``y]

Operator overloading is supported as long as at least one parameter is not a built-in primitive - struct and object types are always eligible:

def operator+(xyzStruct a, xyzStruct b) -> xyzStruct
{
    return xyzStruct {x = a.x + b.x, y = a.y + b.y, z = a.z + b.z};
};

Templates and contracts can be attached to operator definitions.

The chain operator <- passes the right-hand result as the first argument to the left-hand function:

int z = foo() <- bar();   // == foo(bar())

And <~ on a function declaration emits musttail, guaranteeing zero stack growth for tail-recursive functions:

def trampoline(int n) <~ int;

Contracts and Macros

Contracts are pre/post conditions attached to functions:

contract positive { assert(x > 0, "x must be greater than zero"); };

def sqrt_int(int x) -> int : positive
{
    // x is guaranteed > 0 here
};

Parameterized contracts match the arity of the function they're attached to.

Macros are expression-only and expand at the call site:

macro CLAMP(val, lo, hi)
{
    (val, lo, hi) ((val) < (lo) ? (lo) : (val) > (hi) ? (hi) : (val))
};
int c = CLAMP(x, 0, 255);

Macros and contracts can be mixed on the same function.

Enums, Unions, and the Preprocessor

Enums are typed:

enum Color { Red, Green, Blue };

Color c = Color::Red;

Unions share memory across members in the usual way, declared like structs.

The preprocessor is minimal: #import, #dir, #def, #ifdef, #ifndef, #else, #warn, #stop. #dir adds a path to the search list. #stop hard-halts compilation with a message.

Putting It Together:

#import "standard.fx";

using standard::io::console;

struct myStru<T>
{
    T a, b;
};

def foo<T, U>(T a, U b) -> U
{
    return a.a * b;
};

def bar(myStru<int> a, int b) -> int
{
    return foo(a, 3);
};

macro macNZ(x)
{
    x != 0
};

contract ctNonZero(a,b)
{
    assert(macNZ(a), "a must be nonzero");
    assert(macNZ(b), "b must be nonzero");
};

contract ctGreaterThanZero(a,b)
{
    assert(a > 0, "a must be greater than zero");
    assert(b > 0, "b must be greater than zero");
};

operator<T, K> (T t, K k)[+] -> int
:     ctNonZero(  c,   d), // works on arity and position, not identifier name.
ctGreaterThanZero(e,   f)
{
    return t + k;
};

def main() -> int
{
    myStru<int> ms = {10,20};

    int x = foo(ms, 3);

    i32 y = bar(ms, 3);

    println(x + y);

    return 0;
};

Current State

The standard library is actively growing - JSON, UUIDs, networking, hashing, and encryption are all in progress. Bootstrapping - rewriting the compiler in Flux - is the next major milestone. There's a GitHub repository, Discord server, and website if you want to follow along or get involved.

Repo: https://github.com/kvthweatt/Flux
Discord: discord.gg/wVAm2E6ymf

DEV Community: Karac Thweatt

The Language After Rust and Zig

Algebraic Types? Type Geometry? How Far Can a Language Be Pushed? Compile-Time Execution, Relational Interfaces, and More

Flux: The New Programming Language Built for Tomorrow’s CPUs

The Hardware Shift: CPUs Are Scaling Cache, Not Clock Speed

The Flux Advantage: Stack-by-Default Design

Competitive Edge: Why Flux Outperforms C, Rust, and Others

Why Flux Is Future-Proof for the New CPU Era

The Future is Flux

Where Can I Get Flux?

[Boost]

Flux - the new programming language is built for speed, easy to read, and familiar.

Flux - the new programming language is built for speed, easy to read, and familiar.

Hello, World

Variables and Primitives

Functions

Control Flow

Structs

Objects

Error Handling

Memory and Pointers

The data Type and Bit-Level Work

Operators

Contracts and Macros

Enums, Unions, and the Preprocessor

Putting It Together:

Current State

The `data` Type and Bit-Level Work