Forem: Dimension AI Technologies

Just what IS Nim, anyway?

Dimension AI Technologies — Sun, 15 Mar 2026 09:57:24 +0000

The language that separated logic from its execution environment

Imagine your team has built a real-time analytics engine – event ingestion, aggregation, threshold detection – and the core logic is correct, fast, and well tested.

Now it has to live in three places: the Linux backend service is C, the Windows desktop monitoring tool is C++, and the browser dashboard is TypeScript. The same aggregation algorithm has therefore been implemented three times, and when the threshold logic changes, three codebases must be updated, retested, and redeployed independently. The maintenance cost is no longer proportional to the complexity of the logic – it is proportional to the number of environments the logic must inhabit.

TypeScript demonstrated part of this idea — the language sits above its runtime and generates JavaScript — but targets a single managed environment. Nim applies the same principle to C, with a critical difference: it generates code that can manage raw pointers, manual memory, and direct hardware access, and it does so across three active backends — C, C++, and JavaScript (with Objective-C still present as a legacy option).

nim c   app.nim   # native binary via C
nim cpp app.nim   # C++ integration
nim js  app.nim   # browser application via JavaScript

The same source file produces three different outputs for three different execution environments, because the backend is not the language's identity – it is a parameter.

Logic versus physics

Most systems languages bind the logic of a program to the physics of its execution. In C, Rust, or Odin, the algorithm and the execution model are tightly coupled. Ownership rules, ABI conventions, memory layout, and runtime behaviour are not optional layers that can be swapped out; they are part of what the language is.

Nim separates these layers. The durable artefact in its compilation model is the abstract syntax tree – the structured representation of the program before it is lowered into any particular environment. Backend selection determines how that logic is realised, but the logic itself remains constant.

Earlier articles in this series used "physics" to describe C's fixed execution rules – memory model, ABI, and calling conventions. Nim's architecture treats those rules as variable, selectable at compile time. That variability is precisely what separates Nim from every other language in the series.

A language defined by its AST rather than by a single runtime becomes a generator of programmes — capable of inhabiting different execution environments because the logic is treated as primary and the physics as contingent.

C as infrastructure

The first article in this series argued that C's lasting importance lies not in the language itself but in the infrastructure around it: its ABI, its portability, and its toolchain. Nim attaches itself to exactly that infrastructure. By generating C, it inherits the entire C ecosystem – compilers, optimisers, debuggers, profilers, and library access – without building any of it. This is commensal architecture: Nim gains reach by living within the surrounding ecosystem without attempting to replace it.

The contrast with Zig is sharp: Zig rebuilt the C toolchain and positioned itself as a better C compiler, while Nim leaves the existing toolchain intact and emits code for compilers developers already have. Both languages treat C as central to their strategy, but they occupy opposite sides of the compilation boundary.

The cost of that dependence is real: Nim does not own its compilation pipeline, and debug information maps to the generated C rather than always cleanly to the Nim source. The language is, structurally, a guest in someone else's toolchain.

Reach versus depth

This distinction clarifies Nim's position in the series.

Odin represents a strategy of depth. Its design asks how data sits in memory, how cache lines are used, and how programmes align themselves with hardware behaviour. The #soa annotation, built-in vector types, and the implicit context system all follow from a single organising principle: data layout over control flow.

Nim represents a strategy of reach. Its design asks how one body of logic can survive contact with many execution environments without being rewritten — and unlike JVM or .NET languages, which achieve cross-platform deployment through a shared runtime, Nim achieves it through compile-time generation, producing native code for each target without requiring a runtime beneath it. The multi-backend compiler, configurable memory management, and powerful macro system all follow from a different organising principle: the separation of logic from the physics of its execution.

Odin narrows around one strong constraint. Nim stays broad because it must map onto different runtime models – native binaries via C, library integration via C++, and browser applications via JavaScript. A language that wants to inhabit all three cannot afford to be defined too tightly by any one of them, and that breadth is not a failure of focus but the direct consequence of the architectural choice that defines the language.

Memory management as configuration

Nim's most unusual technical feature follows directly from the logic/physics separation, and it is the clearest evidence that the separation is real rather than theoretical.

Most modern systems languages choose one memory management philosophy and embed it in the language design: Rust enforces ownership and borrow checking, Go uses a tracing garbage collector, and Zig requires explicit allocator parameters. Each bakes its approach into the grammar and type system.

Nim treats memory management as configuration.

nim c --mm:arc  app.nim    # automatic reference counting
nim c --mm:none app.nim    # manual memory management

The same source code, compiled with different flags, produces different runtime behaviour. Consider a function that allocates a buffer:

proc processData() =
  var buf = newSeq[byte](4096)
  buf[0] = 42
  # scope exits here — what happens to buf?

Under --mm:arc, the generated C contains reference-counting machinery. The compiler inserts a cleanup call at scope exit that frees buf automatically – deterministic destruction, similar in effect to C++'s RAII. Under --mm:none, that machinery is absent. Lifetime responsibility shifts entirely to the programmer. To see the difference, look at what the compiler actually emits:

/* Generated C under --mm:arc (simplified) */
void processData(void) {
    NimSeq* buf = newSeq(4096);
    buf->data[0] = 42;
    nimDecRefAndFree(buf);   /* ← inserted by the compiler */
}

/* Generated C under --mm:none (simplified) */
void processData(void) {
    NimSeq* buf = newSeq(4096);
    buf->data[0] = 42;
    /* ← nothing. Lifetime management is the programmer's responsibility. */
}

The Nim source is identical in both cases, but the generated C is not – the memory management strategy has moved out of the language and into the compilation configuration.

Nim is not interesting here because it supports reference counting – C++ already has deterministic destruction. Nim is interesting because it allows the choice of lifetime strategy to move out of the language's identity and into compilation configuration. Memory management becomes part of the execution physics rather than part of the programme's logic.

That flexibility buys reach. A library compiled with --mm:arc can ship as a managed component; the same library compiled with --mm:none can be embedded in a bare-metal environment where no runtime overhead is acceptable. The flexibility also gives up the kind of compile-time guarantees that Rust can make only because it refuses such flexibility. Rust's ownership model can prove absence of use-after-free and data races precisely because the memory rules are fixed. Nim's switchable model cannot, because the rules change depending on the flag.

Macros as the adapter layer

In a single-backend language, macros are a convenience. In a multi-backend language, they become the primary mechanism for adapting high-level intent to backend-specific implementations.

Nim macros operate directly on the abstract syntax tree during compilation, using ordinary Nim syntax rather than a separate metalanguage. The simplest form of backend adaptation is conditional compilation:

when defined(js):
  proc getTimestamp(): float = {.importjs: "Date.now()".}
else:
  proc getTimestamp(): float =
    # native implementation via C's clock_gettime

But the deeper capability is AST transformation. A macro can receive a block of code as a syntax tree, inspect its structure, and emit a rewritten version – all at compile time:

import macros

macro serialise(body: untyped): untyped =
  # receives the body as an AST node
  # walks the tree, finds field declarations
  # emits read/write procedures for each field
  # the generated code compiles against whichever backend is active
  result = buildSerialiser(body)

The distinction matters: conditional compilation chooses between existing code paths, whereas AST macros generate code paths that did not exist in the source. A macro could, for instance, accept a high-level concurrency intent and emit pthreads calls for the C backend but Web Workers setup for the JavaScript backend — same logical operation, different execution physics, generated from a single source definition. Without this capability, adapting a single codebase to multiple backends would collapse into layers of manual wrappers and platform-specific branches.

The cost is the same tension the Clojure article in this series identified: expressive metaprogramming that individual experts wield productively and teams struggle to maintain.

Where Nim's design fits

Nim's architecture works best where deployment diversity is unavoidable.

The strongest production example is the Ethereum ecosystem. The Nimbus clients, developed by Status, are substantial Nim codebases that produce efficient native binaries while operating inside an infrastructure dominated by C and Go implementations. Status has used Nim across multiple components of its distributed messaging platform, showing that the language has been used for substantial production workloads.

Scientific and numerical computing provides a second family of examples. Arraymancer is a tensor library aimed at CPU, CUDA, and OpenCL workloads. SciNim exists as an explicit initiative to build scientific computing infrastructure around the language. Both exploit Nim's ability to generate C that links directly against established numerical libraries.

What these cases share is a specific engineering condition: a core algorithm that must operate inside ecosystems built in other languages. Nim's value is clearest when the alternative is maintaining parallel implementations across those ecosystems.

Limitations and the adoption paradox

Languages that achieve institutional adoption usually do so by imposing visible constraints: Rust tells teams what they cannot do with memory, Go tells teams roughly how everyone else will write, and Zig tells teams where hidden behaviour is not allowed. These constraints make codebases legible across teams and give organisations confidence that new hires will produce code consistent with the existing base.

Nim offers a larger design space. Configurable memory models, macro-based DSL construction, and multiple backends give expert developers unusual power. They also make standardisation harder. Two experienced Nim developers may write code that looks nothing alike, using different paradigms, different macro patterns, and different memory strategies. Large organisations often adopt constraints precisely because constraints make codebases predictable. Nim's flexibility works against that institutional need.

That is the deeper adoption problem – not marketing, but institutional trust.

Nim has been stable and capable for over a decade. It has not achieved critical mass. At some point the question shifts from "what still needs to be improved?" to "does the market have room for another general-purpose compiled language whose main virtue is flexibility?" The honest answer in 2026 is: probably not at large scale, unless the language finds a narrow domain it can own completely.

The practical limitations compound this. The package ecosystem is smaller than Rust's, Go's, or Python's. Debugging can expose generated C rather than Nim source, reminding developers that the language operates as a layer above another toolchain. LLM training data for Nim is thin compared with mainstream languages, making AI-assisted development less reliable – a compounding disadvantage in an era where coding agents are increasingly central to developer productivity.

Competitors

Zig and Nim both treat C as central to their strategy, but from opposite directions: Zig became a C compiler, absorbing the toolchain and offering to build C code better than GCC does, while Nim became a C generator, emitting code for the existing toolchain and letting it handle the rest. Both keep C's physics, but they differ on which side of the compilation boundary they occupy.

No other mainstream compiled language separates the programming language from its compilation target to the degree Nim does.

Conclusion

Programming languages are usually defined by where their programmes run – the compilation target determines the runtime behaviour, the tooling, and the surrounding ecosystem.

Nim reversed that relationship. By treating the backend as variable and the AST as canonical, it separated the logic of the program from the physics of its execution more decisively than any other language in this series.

Within the landscape explored by this series, Odin pursues depth, Zig pursues control over the toolchain, and Nim pursues reach.

Its achievement is real: it demonstrates that one body of logic can inhabit many environments without surrendering its identity at the source level. Its paradox is equally real: a language that can inhabit almost any role eventually struggles to claim one of its own.

This article is part of an ongoing series examining what programming languages actually are and why they matter.

Language	Argument
C	The irreplaceable foundation
Python	The approachable ecosystem
Rust	Safe systems programming
Clojure	Powerful ideas, niche language
Zig	Rebuild the toolchain, keep the physics
Odin	Data layout over control flow
Nim	Logic separated from execution

Just What IS Odin, Anyway?

Dimension AI Technologies — Wed, 11 Mar 2026 17:17:42 +0000

The language that treats the cache line as a design principle

Imagine you are a game-graphics programmer writing what's known as a "particle system" – a technique used in real-time graphics to render large numbers of small, short-lived visual objects such as sparks, smoke, fire, and rain. Each particle is a lightweight data record with position, velocity, colour, lifetime, and a handful of flags, and a typical system manages tens of thousands of them simultaneously, updated sixty times per second. It is one of the clearest cases in software where data layout dominates performance.

You have written the obvious code: a struct containing all the fields, an array of ten thousand structs, a loop that updates position from velocity each frame.

The profiler tells you the update loop is slow. Not algorithmically slow – the work per particle is trivial – but memory slow. The CPU is stalling, waiting for data to arrive from main memory. The reason is a classic data layout problem: Array of Structures (AOS) versus Structure of Arrays (SOA). You are running through an array of structs, but on each iteration the cache line loads position, velocity, colour, lifetime, and every flag. The update only touches position and velocity. The rest is dead weight, dragged through the cache on every iteration, evicting data you actually need.

You know the fix. You've known it for years. Convert the AOS to an SOA: one contiguous array of positions, another of velocities, another of colours. Now the update loop streams through two tightly packed arrays and the cache line contains nothing but data the loop actually reads.

The problem is that in most mainstream languages, this fix becomes a refactoring project. In C, you tear apart the struct and rewrite every access pattern. In C++, you write a template library or reach for an ECS framework. In Rust, you restructure your data model and update every borrow. In Zig, you write the SOA layout manually and adjust the allocator calls. The conceptual change is one sentence: "store the data by field, not by record." The implementation change is days of work and a significant source of bugs.

Now imagine a language where that change is a single annotation on the struct declaration, and the compiler handles the rest.

That language exists. It is called Odin. And the annotation – #soa – is not a library feature or a compiler extension. It is part of the language, because Odin is explicitly designed around how data moves through hardware, rather than how logic flows through code.

Why data layout matters

Modern CPUs do not fetch individual bytes from memory. They fetch cache lines – typically 64 bytes at a time. If a data structure contains ten fields but a loop only touches two of them, eight fields' worth of memory are loaded and discarded on every iteration. The cost is not the computation; it is the wait. On modern hardware, a cache miss can cost 100–200 CPU cycles – the CPU can perform several hundred arithmetic operations in the time it takes to fetch a single cache line from main memory.

Game development discovered this problem earlier than most of the software industry, because games run fixed-budget loops at 60 or 120 frames per second. A few hundred unnecessary cache misses per frame can be the difference between smooth rendering and visible stutter. The discipline that emerged – data-oriented design, articulated most influentially by Mike Acton in his widely cited 2014 CppCon talk – reorganises software around memory access patterns rather than object hierarchies.

Data-oriented design has been practised in C and C++ for decades, but always as a discipline imposed on top of the language. The language itself provides no support for it. C structs are always arrays-of-structures. C++ classes encourage bundling behaviour with data, which pushes against cache-friendly layout in many codebases. Rust and Zig are primarily organised around control flow and procedure structure; both leave layout optimisation to the programmer.

Odin was designed by Bill Hall (known as gingerBill), who had been doing this work manually for years and decided the language itself should handle it. The result is a systems language that keeps C's fundamental execution rules – its memory model, its programmer-managed resources, its C-compatible ABI – but reorganises everything above that foundation around data layout.

(This series uses "physics" to mean a language's fundamental execution rules – memory model, execution model, and binary interface. Odin keeps C's physics, as Zig does; the difference is what each language builds on top of that shared foundation.)

How data-orientation shapes the language

Mainstream systems languages foreground control flow: functions, conditionals, loops, call stacks, scope rules. The programmer thinks in terms of "what happens next." Odin foregrounds data layout instead: how structures sit in memory, how they travel through cache lines, how they're accessed in bulk. That single reorientation explains every distinctive feature of the language.

SOA as a built-in

In Odin, converting an Array of Structures to a Structure of Arrays is a directive on the type, not a restructuring of the codebase:

// Array of Structures (default)
particles: [10000]Particle

// Structure of Arrays — same data, cache-friendly layout
particles: #soa [10000]Particle

The compiler rearranges the memory layout. Crucially, access syntax remains identical – particles[i].position works the same way regardless of whether the underlying storage is AOS or SOA. The programmer changes one annotation; the data moves through the cache differently; every line of code that reads or writes the data compiles without modification.

To appreciate what this eliminates, consider what the same transformation requires in C:

// C: the struct must be torn apart into parallel arrays
float pos_x[10000], pos_y[10000], pos_z[10000];
float vel_x[10000], vel_y[10000], vel_z[10000];
float lifetime[10000];
uint32_t flags[10000];
// Every access pattern that touched the original struct must be rewritten.

In C, the refactoring is structural and pervasive. In C++, you would typically reach for a template library or an Entity Component System framework to manage the transformation. In Rust, the data model restructuring propagates through every borrow and lifetime annotation. In Odin, it is a single keyword.

This is the clearest illustration of the thesis. In a control-flow-oriented language, layout is a consequence of how the programmer defines types. In Odin, layout is a first-class design decision that the language supports directly.

Built-in vector and matrix types

Most languages treat vectors and matrices as library types. Odin treats them as primitives:

pos: [3]f32            // a 3-element vector
mat: matrix[4,4]f32    // a 4×4 matrix
result := mat * pos    // native operation, no library call

In C++, Eigen or GLM provide these operations, but as template libraries with their own compilation costs and diagnostic noise. In Rust, basic linear algebra requires importing a crate – nalgebra, glam, or similar – and often involves working around the type system to ensure correct alignment. In Odin, vectors and matrices are native types that the compiler can map efficiently to SIMD instructions, with no external library dependency and without the extra indirection of a library-defined numeric type. Because the compiler knows these are vector types rather than arbitrary structs, it can make alignment and packing guarantees that library-based solutions must work around.

This choice only makes sense if the language is designed around data. If your organising principle is control flow, vector types are a library concern. If your organising principle is how data is arranged and moved, they are as fundamental as integers.

No constructors, no destructors

Odin has neither. Structs are inert data – they zero-initialise by default, and the programmer manages lifecycle explicitly:

// Odin: data is passive. No constructor. No destructor. Zero-initialised.
p: Particle  // all fields are zero
p.lifetime = 5.0
// When p goes out of scope, nothing happens. No Drop, no destructor, no hidden call.

Compare with C++, where constructing an object may invoke an arbitrary constructor, and where scope exit triggers type-defined destruction logic that is not visible at the declaration site:

// C++: what happens when this object is created? When it's destroyed?
// The answer depends on the class definition, which may be in another file.
Particle p;      // constructor runs — doing what?
// ... use p ...
// scope exit: destructor runs — doing what?

The absence of constructors and destructors is perhaps the most consequential omission in the language, and it follows directly from the data-oriented model: if data is passive and the programme's job is to transform it in bulk, then attaching behaviour to individual records is often the wrong abstraction for that workload. It hides per-record work inside what should be a bulk operation, and it couples data to behaviour in precisely the way data-oriented design seeks to avoid. Odin achieves simplicity not by adding more semantic machinery, but by refusing to attach lifecycle behaviour to the data in the first place.

The context system

The Zig article in this series explained explicit allocator parameters as a consequence of the transparency principle: every function that allocates memory declares that fact in its signature. Odin solves the same problem – who controls memory allocation – but arrives at a different answer.

Every Odin procedure has access to an implicit context value, passed on the stack, containing the current allocator, temporary allocator, logger, and assertion handler. Any procedure can override the context for its callees by modifying its own copy:

// Odin: switch the allocator for everything called within this scope
context.allocator = my_arena_allocator
process_batch(particles)
// process_batch and everything it calls will use my_arena_allocator

No function signatures change. No explicit parameters are threaded through the call graph. The allocator flows through the programme as environmental data.

The equivalent operation in Zig requires the allocator to appear in every function signature in the call chain:

// Zig: the allocator must be passed explicitly at every level
fn process_batch(allocator: std.mem.Allocator, particles: []Particle) !void {
    // every sub-call that allocates also needs the allocator parameter
    try process_chunk(allocator, particles[0..chunk_size]);
}

In codebases where allocators and scratch state are pervasive – which describes most data-heavy systems – threading an allocator parameter through every function signature adds noise to every call site. Odin chooses ambient context because it reduces that noise. The practical justification is straightforward: in a codebase processing ten thousand particles per frame, the allocator is environmental infrastructure, not per-function state. The context system treats it accordingly.

The trade-off is real. Context is implicit. A function's signature does not tell you whether it allocates memory. This is the inverse of Zig's guarantee. Odin sacrifices signature transparency for lower per-function noise, and developers coming from Zig or Rust will notice the loss.

Where Odin's design assumptions match reality

Three conditions align with Odin's architecture.

The first is real-time graphical software: game engines, simulation tools, renderers – systems where the frame budget is fixed and cache performance dominates. This is Odin's strongest territory and the domain that produced it. JangaFX's EmberGen, a real-time volumetric fluid simulation tool, is built in Odin and is the most prominent production example.

The second is bulk data transformation: any system that processes large homogeneous datasets where the access pattern is "stream through a large array and transform each element." Physics simulation, audio DSP, rendering pipelines, GPU data preparation, and signal processing all share this characteristic. SOA layout and SIMD-friendly primitives provide direct, measurable performance gains in these contexts, and they are domains where data layout routinely dominates performance.

The third is systems work where Rust's constraints impose excessive friction and Zig's explicitness imposes excessive noise. Odin occupies a middle ground: more guardrails than C (bounds-checked arrays, zero-initialisation), fewer constraints than Rust (no borrow checker), less ceremony than Zig (implicit context rather than explicit allocator parameters). For developers who find Rust over-constrained and Zig over-explicit for their problem domain, Odin is a coherent alternative.

Where the assumptions do not match: if formal memory safety is required – safety-critical systems, security-sensitive code – Rust remains the strongest mainstream option. If C ABI stewardship and toolchain integration are the priority, Zig's infrastructure-first approach is stronger. If the workload is not data-heavy – business logic, string processing, network protocol handling – Odin's data-oriented features provide no advantage and its smaller ecosystem becomes a net cost.

Limitations

Odin's limitations are real and should be weighed honestly.

The package ecosystem is substantially smaller than Rust's, Go's, or Zig's. Many domains have no established library. Developers frequently need to write bindings or implement functionality from scratch.

Odin remains largely the vision of a single designer – Bill Hall. This produces unusual design coherence but also concentrates project risk. There is no Odin Foundation, no corporate sponsor, and no clear succession plan. For organisations evaluating multi-year commitments, the trade-off between coherence and institutional continuity is real.

The language provides practical safety improvements over C – bounds checking, zero initialisation – but no compile-time memory safety model. For domains where safety guarantees are contractually or regulatorily required, Odin is not a candidate.

IDE support, debugging, and profiling tools are functional but less mature than the equivalents for Rust, Go, or Zig. The language server (OLS) is under active development but not yet at the level of rust-analyzer or ZLS.

Odin's association with game development, while accurate to its origins, creates a perception problem. Developers outside the games industry may dismiss it as domain-specific without evaluating its broader applicability. The language is general-purpose in capability but niche in reputation.

As with Zig, LLM training data for Odin is thin. AI-assisted development – an increasingly material factor in language productivity – is less reliable for Odin than for mainstream languages, and this gap compounds the ecosystem and documentation limitations.

Competitors

Zig occupies the closest territory – the same layer of the stack, the same "better C" positioning – but its organising principle is infrastructure and transparency, not data layout. The Zig article in this series argued that Zig rebuilt the C toolchain; Odin redesigned the programming model above the C foundation.

Hare and C3 remain closer to C's original procedure-oriented design and do not prioritise data layout as a language-level concern. Rust's data layout control (repr(C), manual packing) exists but is secondary to its ownership model.

Odin's nearest conceptual relative is not another programming language but the Entity Component System pattern in game engine architecture – a design pattern that Odin promotes to a language-level primitive, chiefly through #soa.

Conclusion

For fifty years, systems languages have been designed around the question: "What should the programme do next?" Odin asks a different question: "Where does the data live, and how does it get to the processor?"

That reorientation produces a language that looks superficially like C – manual memory, explicit control, no garbage collector – but is organised around a fundamentally different principle. SOA as a built-in, vectors as primitives, context as implicit data flow, and the absence of per-object lifecycle machinery all follow from the decision to treat the cache line, not the call stack, as the primary unit of design.

Whether that principle has broad applicability beyond its origins in real-time graphics is an open question. But as hardware continues to widen the gap between compute speed and memory latency, the question Odin asks is becoming harder for the rest of the industry to ignore.

This article is part of an ongoing series examining what programming languages actually are and why they matter.

Language	Argument
C	The irreplaceable foundation
Python	The approachable ecosystem
Rust	Safe systems programming
Clojure	Powerful ideas, niche language
Zig	Rebuild the toolchain, keep the physics
Odin	Data layout over control flow

Coming next: Nim – where Odin's data-oriented design is a strategy for depth, Nim's transpilation to C is a strategy for reach.

Just what IS Zig, Anyway?

Dimension AI Technologies — Wed, 11 Mar 2026 08:42:11 +0000

And why are people using it without writing a line of it?

Most programming languages spread because developers write code in them. A developer tries the syntax, likes the ergonomics, builds something, and tells a colleague. Some languages gain traction through adjacent tooling or frameworks – TypeScript through Angular, Kotlin through Android – but the language itself is still the point. The tooling serves the code.

Zig has followed a different path. One of its most widely discussed real-world uses is zig cc – a drop-in C and C++ cross-compilation toolchain that teams adopt to compile code written in other languages, without writing or intending to write a single line of Zig. Uber engineers have adopted it for C++ cross-compilation. The Bun JavaScript runtime chose Zig partly for the language but substantially because the toolchain solved cross-compilation problems that were otherwise intractable. These are prominent examples rather than proof of universal adoption – the evidence base is still developing – but the pattern is consistent enough to demand explanation, particularly for a project that has not yet reached version 1.0. The language enters organisations through the compiler, not through the syntax.

The standard description of Zig – "a better C" – is accurate in the narrow sense that Zig occupies the same layer of the software stack and shares C's execution model.

But it obscures the more interesting truth: where Rust fixes C by replacing the language with a fundamentally different memory model, Zig fixes C by rebuilding its infrastructure – the compiler, the build system, the cross-compilation machinery – into a hermetic, portable package, while leaving C's raw execution model and ABI intact.

Rust replaces C's code but keeps C's interfaces; Zig rebuilds C's tools but keeps C's physics.

The toolchain

The first article in this series argued that C's importance derives from the ABI – the universal binary interface that every other language targets at its boundaries. If that is true, then the tool that manages that ABI most competently acquires strategic importance. Zig understood this before most of its competitors did.

zig cc bundles a patched Clang/LLVM frontend with platform headers into a single, portable binary. A developer can cross-compile C or C++ to any supported target from any host machine without installing platform-specific toolchains, sysroots, or header packages. The crucial detail is that Zig ships what it calls bundled libc targets – musl and glibc headers for many architectures – inside its own distribution. That is what makes the cross-compilation hermetic rather than merely convenient.

Without Zig, building a C program for Linux ARM64 from a macOS x86 host typically requires installing a cross-compiler, obtaining the correct sysroot, configuring include and library paths, and debugging linker errors. The process is fragile, poorly documented, and different for every target triple.

Traditional cross-compilation for Linux ARM64 from macOS:

# Install a cross-compiler, obtain a sysroot, configure paths...
brew install aarch64-linux-gnu-gcc
export SYSROOT=/path/to/aarch64-linux-gnu/sysroot
aarch64-linux-gnu-gcc -o myapp main.c \
    --sysroot=$SYSROOT \
    -I$SYSROOT/usr/include \
    -L$SYSROOT/usr/lib

The same operation with Zig:

zig cc -target aarch64-linux-gnu -o myapp main.c

zig cc reduces this to a single command with the target specified as a flag.

The strategic consequence is unusual. Every other "better C" language asks developers to leave the C ecosystem. Zig absorbs it. A team can adopt zig cc without writing a single line of Zig, without changing any source code, and without altering any interfaces. The cost of adoption is close to zero. The language becomes available as an option once the toolchain is already in use. The toolchain opens the door; the language follows.

The contrast with Rust is instructive. Both languages interoperate with the C ABI, and both use LLVM as a backend. The real difference is the memory model: Rust replaces it; Zig retains it. Rust's FFI requires extern "C" blocks, unsafe wrappers, and often a binding generator such as bindgen:

// Rust: calling C's strlen requires an unsafe block and a manual declaration
extern "C" {
    fn strlen(s: *const c_char) -> usize;
}

fn length(s: &CStr) -> usize {
    unsafe { strlen(s.as_ptr()) }  // every call crosses an unsafe boundary
}

Zig can @cImport a C header directly, which works by invoking zig translate-c under the hood – a mechanical translation step that parses C declarations into Zig types:

// Zig: import the C header; call the function as though it were Zig
const c = @cImport(@cInclude("string.h"));

fn length(s: [*:0]const u8) usize {
    return c.strlen(s);  // no wrapper, no unsafe block, no binding generator
}

The interop cost is structurally lower because Zig kept C's memory model and calling conventions.

Transparency

If the toolchain is Zig's adoption strategy, transparency is its design philosophy. Zig's stated principle is: no hidden control flow, no hidden allocations. If you do not see a function call in the code, no function call occurs. If you do not see a memory allocation, no memory is allocated. Every operation is visible at the call site.

This is easier to understand through a concrete comparison. Consider a routine operation: appending an element to a dynamic array.

In C, realloc may be called inside a library function. The caller cannot tell from the call site whether memory will be allocated, how much, or what happens on failure. The convention is to check a return value, but nothing in the language enforces this.

In C++, std::vector::push_back may reallocate the backing buffer, invoke copy or move constructors, and – if an exception is thrown – unwind the stack through destructors. None of this is visible at the call site. The programmer must know the type's implementation to reason about what happens.

// C++: what happens behind this line?
items.push_back(value);
// Answer: possibly realloc, possibly copy/move constructors on every element,
// possibly an exception, possibly stack unwinding through destructors.
// The call site tells you none of this.

In Rust, Vec::push may reallocate. When the old buffer is dropped, Drop runs automatically. The borrow checker prevents dangling references, but the programmer cannot see from the call site alone what cleanup will occur or when.

In Zig, the function takes an Allocator parameter explicitly. The append call returns an error union. If allocation fails, the error is a normal return value in the caller's control flow. No destructors run. No exceptions are thrown. No implicit function calls occur. The call site is a complete description of what the machine will do.

fn appendItem(list: *std.ArrayList(u32), allocator: std.mem.Allocator, value: u32) !void {
    try list.append(allocator, value);
}

The point is not that the other languages are wrong. Each hides a different amount of machinery behind the call site, and each has reasons for doing so. Zig hides the least. The cognitive load of reasoning about what a line of Zig does is lower than the equivalent line in C++, because there is less invisible behaviour to account for.

The allocator pattern

The explicit allocator is central to how this works in practice. Zig's standard library functions that allocate memory require an Allocator to be passed as a parameter. This single design decision has several consequences.

Any function signature that includes an Allocator parameter declares, at the type level, that it may allocate memory. Any function signature that does not include one is guaranteed not to allocate. Tests can substitute a different allocator – a failing allocator, a tracking allocator, a fixed-buffer allocator – without changing the code under test. In systems with strict memory budgets – embedded devices, databases, game engines – the allocator pattern makes resource consumption auditable at the API boundary. And out-of-memory is a normal error return, not an abort or an exception. The caller decides what to do.

In C, allocation failure is easy to ignore:

// C: nothing forces the programmer to check this
char *buf = malloc(4096);
memcpy(buf, src, len);  // if malloc returned NULL, this is undefined behaviour

In Zig, the error is part of the return type and the compiler will not let the caller ignore it:

// Zig: the caller must handle the error or explicitly propagate it
const buf = allocator.alloc(u8, 4096) catch |err| {
    // OOM is a normal control flow path, not an abort
    return err;
};

Resource exhaustion becomes a first-class engineering concern rather than a runtime surprise.

The trade-off must be stated honestly. Zig does not prevent use-after-free, dangling pointers, or data races at compile time. It keeps C's physics – including the dangers that come with them – and the programmer remains responsible for memory correctness. Zig's position is that if every operation is visible and every allocation is explicit, the programmer can reason about correctness directly – and that this is preferable, for certain classes of work, to the indirection and constraint of a borrow checker. Whether that bet pays off at scale is an open question. Zig's largest production users suggest it can, but the evidence base is still narrow compared to Rust's.

Comptime

Comptime is the mechanism that keeps the language small despite its toolchain ambitions. Zig's toolchain does a great deal; the language itself does remarkably little, because comptime collapses several distinct features into one.

Any expression or block in Zig can be marked comptime, which instructs the compiler to evaluate it during compilation rather than at runtime. The code that runs at compile time is ordinary Zig – the same syntax, the same semantics, the same standard library. There is no separate macro language, no template metalanguage, no preprocessor.

Language	Compile-time mechanisms
C	Preprocessor (`#define`, `#ifdef`)
C++	Templates, constexpr, macros
Rust	Generics, proc macros, const fn, build.rs
Zig	comptime (one mechanism)

The structural consequence is most visible in how generics work. Zig does not have a generics subsystem. In Rust, generics are a distinct wing of the compiler architecture with their own syntax, trait bounds, and monomorphisation rules. In C++, templates are an entire sub-language with its own error messages, its own instantiation model, and its own debugging challenges:

// C++: a generic linked list requires the template sub-language
template <typename T>
struct LinkedList {
    struct Node {
        T data;
        Node* next = nullptr;
    };
    Node* head = nullptr;
};
// Errors in templates produce notoriously unreadable diagnostics.
// The template system is a distinct language-within-a-language.

In Zig, a generic data structure is a function that takes a type parameter at comptime and returns a struct:

fn LinkedList(comptime T: type) type {
    return struct {
        const Node = struct {
            data: T,
            next: ?*Node = null,
        };
        head: ?*Node = null,
    };
}

That entire architectural wing – generics, template specialisation, trait resolution – is deleted and replaced by a function call that happens to run at compile time. One mechanism does the work of four. This is simplicity in the sense the Clojure article in this series discussed – fewer entangled concepts, fewer distinct syntactic forms – rather than mere ease of use.

The build system is where comptime meets the toolchain. Zig's build system is a Zig program – not a separate tool like Make, not a separate language like CMake, not a domain-specific configuration format like Cargo.toml. Because the build system is Zig, it has full access to comptime, to the standard library, and to the same cross-compilation targets as the compiler. It can orchestrate mixed C/C++/Zig builds, conditional compilation, dependency fetching, and platform-specific logic – all in one language, in one file. This is the structural link between the toolchain story and the language design: the build system is where they meet.

Where Zig's design assumptions match reality

Three conditions align with Zig's architecture.

The first is an existing C or C++ codebase that must be maintained, not rewritten. The codebase is too large to port to Rust. The build system is fragile. Cross-compilation is manual and error-prone. Zig enters as the toolchain first – zig cc replaces the existing compiler without changing any source code. New modules can then be written in Zig and linked against the existing C code with no FFI layer, because Zig can @cImport C headers directly. This is a gradual adoption path with near-zero switching cost, and of the three conditions, it is the strongest match for Zig's design.

The second is deterministic, resource-constrained systems: databases, game engines, embedded firmware, custom allocators – systems where garbage collection pauses are unacceptable and where the borrow checker's constraints impose friction on the data structures the problem requires. Intrusive linked lists, arena allocators, and memory-mapped I/O are all straightforward in Zig and often require unsafe abstractions in Rust. The explicit allocator pattern makes resource budgets visible and OOM handling a normal code path.

The third is cross-platform binary distribution from a single build environment. A CLI tool, a library, or a runtime that must ship to multiple OS/architecture combinations from a single CI pipeline. Zig's hermetic cross-compilation produces static binaries for each target without requiring platform-specific toolchains on the build machine – and notably, it makes static linking against glibc significantly easier than standard toolchains do, which has historically been a major pain point for C developers targeting Linux. What would otherwise be a multi-day infrastructure project becomes a build flag.

Where Zig's assumptions do not match: if compile-time memory safety guarantees are required, Rust provides them and Zig does not. If a mature ecosystem with extensive library coverage is needed, Rust and Go are years ahead. If API stability between releases is essential, Zig is not there yet. These are not minor caveats.

Limitations

Zig's limitations are significant and should be weighed honestly.

The language is pre-1.0. The standard library APIs have broken between releases and will continue to do so until the specification stabilises. Code written against Zig 0.11 may not compile on 0.13. For production systems, this imposes a maintenance cost that must be weighed against the language's benefits.

Documentation is incomplete. The standard library documentation is auto-generated and sparse. The language reference is thorough but dense. There is no equivalent of the Rust Book or Go Tour – no structured onboarding path for new developers. The primary learning resource remains reading the standard library source code, which is a high barrier to entry.

The package ecosystem is young. Many common libraries – HTTP, JSON, database drivers – exist but are maintained by small teams or individuals. The depth and breadth of crates.io or PyPI is years away. IDE support via ZLS (the Zig Language Server) is functional but less complete than rust-analyzer or gopls. Debugging and profiling support exists through LLVM but is not as well documented as for C or Rust.

There is also the question of AI-assisted development. LLM coding tools are trained predominantly on C, Python, JavaScript, Java, and Rust. Zig's representation in training data is thin. AI-assisted development – an increasingly material factor in language productivity – is less reliable for Zig than for mainstream languages. This gap is likely to narrow, but it has not done so yet, and for teams that rely heavily on agentic coding workflows the practical impact is real.

Competitors

Zig is not the only language attempting to improve on C. Odin prioritises data-oriented design and developer ergonomics – while Zig rebuilds the toolchain for the programmer's environment, Odin builds a better language for the programmer's data. Hare prioritises minimalism and stability, with its own compiler backend (QBE) and a stated intention to freeze the language specification at 1.0. Nim transpiles to C and therefore operates as part of the C infrastructure by definition, though it relies on the host's C compiler rather than shipping its own. C3 stays closest to C's syntax while fixing the preprocessor and adding contracts.

Each made different strategic choices about the toolchain question. Zig is the most prominent language to ship a drop-in C/C++ compiler as a first-class, maintained component of its distribution.

Conclusion

Zig's strategy for entering the systems programming landscape was to recognise that C's dominance rests on infrastructure – the ABI, the toolchain, the build process – not on the quality of the language. Rather than building a better language and hoping the infrastructure would follow, Zig rebuilt the infrastructure and let the language follow.

Whether that strategy succeeds long-term depends on reaching 1.0, stabilising the API, and building an ecosystem deep enough to sustain production use at scale. Those are open questions. But the approach itself – rebuilding the toolchain while keeping the physics – is the most original strategic move in systems language design since Rust replaced the memory model while keeping the ABI.

In systems programming, the compiler has always mattered more than the language. Zig is built on that conviction.

This article is part of an ongoing series examining what programming languages actually are and why they matter.

Language	Argument
C	The irreplaceable foundation
Python	The approachable ecosystem
Rust	Safe systems programming
Clojure	Powerful ideas, niche language
Zig	Rebuild the toolchain, keep the physics

Coming next: Odin – a language for developers who ship software, not papers about shipping software.

Just What IS Clojure, Anyway?

Dimension AI Technologies — Sun, 08 Mar 2026 17:44:46 +0000

Look at this line of code:

processCustomerOrder(customer, orderItems)

Any developer with six months of experience knows roughly what that does. The name is explicit, the structure is familiar, the intent is readable. Now look at this:

(reduce + (map f xs))

The reaction most developers have is immediate and unfavourable. Parentheses everywhere. No obvious structure. It looks less like a programming language and more like a typographer's accident. The old joke writes itself: LISP stands for Lost In Stupid Parentheses.

That joke is, technically, a backronym. John McCarthy named it LISP as a contraction of LISt Processing when he created it in 1958. The sardonic expansion came later, coined by programmers who had opinions about the aesthetic choices involved. Those opinions have not mellowed with time.

And yet Clojure – a modern descendant of Lisp – ranked as one of the highest-paying languages in the Stack Overflow Developer Survey for several consecutive years around 2019. Developers walked away from stable Java and C# positions to build production systems in it. A Brazilian fintech used it to serve tens of millions of customers. Something requires explaining.

The ancestry: Lisp reborn

Clojure only makes sense against the background of Lisp, and Lisp only makes sense as what it actually was: not merely a programming language, but a direct implementation of mathematical ideas about computation.

McCarthy's 1958 creation introduced concepts that took the rest of the industry decades to absorb. Garbage collection, conditional expressions, functional programming, symbolic computation – all present in Lisp before most working developers today were born. Many programmers encounter Lisp's descendants daily without being aware of it.

The defining feature is the S-expression:

(+ 1 2)

Everything is written as a list. This is not merely a syntactic preference. Because code and data share the same underlying structure, a Lisp program can manipulate other programs directly. This property – homoiconicity – is the technical foundation of Lisp macros: code that generates and transforms other code at compile time, with a flexibility that few conventional infix languages match. It is the reason serious Lisp practitioners regard the syntax not as a historical curiosity but as a genuine technical advantage.

Lisp also, however, developed a reputation for producing work that individual experts could write brilliantly and teams could not maintain at all. The tension between expressive power and collective readability never fully resolved. Clojure inherits this tradition knowingly, and is aware of the cost.

What Clojure actually is

The brilliant Rich Hickey created Clojure in 2007. His central design decision was not to build a new runtime from scratch but to attach Lisp to an existing ecosystem.

Layer	Technology
Runtime	JVM
Libraries	Java ecosystem
Language model	Lisp

This host strategy gave Clojure immediate access to decades of mature Java libraries without needing to rebuild any of them. A Clojure developer can call Java code directly. The same logic drove two later variants: ClojureScript, which compiles to JavaScript and found real traction in teams already working with React, and ClojureCLR, which runs on .NET. Rather than fight the unwinnable battle of building its own ecosystem from scratch, Clojure attached itself to three of the largest ones that already existed.

Clojure does not attempt to displace existing ecosystems. It operates inside them.

Central to how Clojure development actually works is the REPL – Read–Eval–Print Loop. Rather than the standard write–compile–run–crash cycle, developers send code fragments to a running system and modify it live. Functions are redefined while the application continues executing. For experienced practitioners this is a material productivity difference: the feedback loop is short, and the distance between an idea and a tested result is small. Experienced Clojure developers report unusually low defect rates, a claim that is plausible given the constraints immutability places on the ways a programme can fail.

The Hickey doctrine: simple versus easy

Hickey's 2011 Strange Loop talk Simple Made Easy is the philosophical engine behind every design choice in Clojure. It draws a distinction that most language design ignores.

Term	Meaning
Easy	Familiar; close to what you already know
Simple	Not intertwined; concerns kept separate

Most languages pursue easy. They aim to resemble natural language, minimise cognitive friction at the point of learning, and reduce the effort required to write the first working programme. This also means that languages favoured by human readers tend to be the hardest for which to write parsers and compilers.

Clojure instead pursues simple. Its goal is to minimise tangled interdependencies in the resulting system, even at the cost of an unfamiliar surface. Writing parsers for Lisps is comparatively straightforward, at the cost of human readability.

Hickey's specific target is what he calls place-oriented programming: the treatment of variables as named locations in memory whose values change over time – mutability, in more formal terms. His argument is that conflating a value with a location generates incidental complexity at scale, particularly in concurrent systems. When you cannot be certain what a variable contains at a given moment, reasoning about a programme becomes difficult in proportion to the programme's size.

The design of Clojure follows directly from this diagnosis. Immutable data, functional composition, minimal syntax, and data structures in place of object hierarchies are all consequences of the same underlying position. The language may not feel easy. The resulting systems are intended to be genuinely simpler to reason about.

The real innovation: data and immutability

Clojure's core model is data-oriented. Rather than building class hierarchies, programmes pass simple structures through functions:

(assoc {:name "Alice" :age 30} :city "London")

This creates a new map. The original is untouched. That is the default behaviour across all of Clojure's data structures – values do not change; new versions are produced instead.

This is made practical by persistent data structures, which use structural sharing. When a new version of a data structure is produced, it shares most of its internal memory with the previous version rather than copying it entirely. The comparison that makes this intuitive for most developers: Git does not delete your previous commits when you push a new one. It stores only the difference, referencing unchanged content from before. Clojure applies the same principle to in-memory data.

The consequence for concurrency results directly from this. Race conditions require mutable shared state. If data cannot be mutated, the precondition for the most common class of concurrency bug does not exist. This was Clojure's most compelling practical argument during the multicore boom of the 2010s, when writing correct concurrent code had become a routine industrial concern rather than a specialist one. Clojure let developers eliminate that entire class of problem.

The functional programming wave – and why easy beat rigorous

Between roughly 2012 and 2020, functional programming moved from academic discussion to genuine industry interest. The drivers were concrete: multicore processors created pressure to write concurrent code correctly; distributed data systems required reasoning about transformation pipelines rather than mutable state; and the sheer complexity of large-scale software made the promise of mathematical rigour appealing.

Clojure was among the most visible representatives of this movement, alongside Haskell, Scala, and F#. Conference talks filled. Engineering blogs ran long series on immutability and monads. For a period it seemed plausible that functional languages might displace the mainstream ones.

What actually happened was different. Mainstream languages absorbed the useful ideas and continued. And the majority of working programmers, it turned out, rarely needed to reason about threading and concurrency at all.

Java gained streams and lambdas in Java 8. JavaScript acquired map, filter, and reduce as first-class patterns, and React popularised unidirectional data flow. C# extended its functional capabilities across successive versions. Rust built immutability and ownership into its type system from the outset. The industry did not convert to functional programming – it extracted what it needed and kept the syntax it already knew.

A developer who can obtain most of functional programming's benefits inside a language they already know will rarely conclude that switching entirely is justified.

The deeper reason functional languages lost the mainstream argument is not technical. It is sociological. Python won because it is, in the most precise sense, the Visual Basic of the current era. That comparison is not an insult – Visual Basic dominated the 1990s because it made programming accessible to people who had no intention of becoming professional developers, and that accessibility produced an enormous, self-reinforcing community. Python did exactly the same thing for data scientists, academics, hobbyists, and beginners, and for precisely the same reason: it is easy to learn, forgiving of error, and immediately rewarding to write. Network effects took care of the rest. Libraries multiplied. Courses proliferated. Employers specified it. The ecosystem became self-sustaining.

Clojure is the antithesis of this process. It is a language for connoisseurs – genuinely, not dismissively. Its internal consistency is elegant, its theoretical foundations are sound, and developers who master it frequently describe it with something approaching aesthetic appreciation. Mathematical beauty, however, has never been a reliable route to mass adoption. Narrow appeal does not generate network effects. And Clojure, by design, operates as something of a lone wolf: it rides atop the JVM rather than integrating natively with the broader currents of modern computing – the web-first tooling, the AI infrastructure, the vast collaborative ecosystems built around Python and JavaScript. At a moment when the decisive advantages in software development come from connectivity, interoperability, and the accumulated weight of shared tooling, a language that demands a clean break from everything a developer already knows is swimming directly against the tide.

Compare this with Kotlin or TypeScript, both of which succeeded in part because they offered a graduated path. A developer new to Kotlin can write essentially Java-style code and improve incrementally. A developer new to TypeScript can begin with plain JavaScript and add types as confidence grows. Both languages have, in effect, a beginner mode. Clojure has no such thing. You either think in Lisp or you do not write Clojure at all.

Where Clojure succeeded

Despite remaining a specialist language, Clojure has real industrial presence.

The most prominent example is Nubank, a Brazilian fintech that reached a valuation of approximately $45 billion at its NYSE listing in December 2021. Nubank runs significant portions of its backend in Clojure, and in 2020 acquired Cognitect – the company that stewards the language. That acquisition was considerably more than a gesture; it was a statement of long-term commitment from an organisation operating at scale.

ClojureScript found parallel influence in the JavaScript ecosystem. The Reagent and re-frame frameworks attracted serious production use, demonstrating that the Clojure model could be applied to front-end development at scale and not merely to backend data pipelines.

The pattern that emerges from successful Clojure deployments is consistent: small, experienced teams working on data-intensive systems where correctness and concurrency matter more than onboarding speed. That is a narrow niche. It was also, not coincidentally, a well-paid one – for a time.

Verdict: the ideas won

Clojure despite its brilliance and initial buzz has not become a mainstream language. By any measure of adoption – survey rankings, job advertisements, GitHub repositories – it remains firmly in specialist territory. Even F#, a functional rival with the full weight of Microsoft's backing - and easier syntax - has not broken through.

But the arguments Clojure made in 2007 has largely been vindicated. Immutability is now a design principle in Rust, Swift, and Kotlin. Functional composition is standard across modern JavaScript and C#. Data-oriented design has become an explicit architectural pattern in game development and systems programming. The industry did not adopt Clojure, but it has been grateful for Hickey's ideas and has in fact hungrily absorbed them.

What did not transfer was the syntax – and behind the syntax lay an economic problem that no philosophical vindication could resolve.

Developers and Heads of Technology might love Clojure for its expressive power and productivity. But a CTO and their C-suite peers evaluating a language does not ask only whether it is technically sound. The questions are: how large is the available talent pool? How long does onboarding take? What happens when a key developer leaves? Does it leave us exposed to key person risk? Clojure's answers to all of these questions are uncomfortable.

There is a further cost that rarely appears in language comparisons. A developer with ten years of experience in Java, C#, or Python carries genuine accumulated capital: hard-won familiarity with idioms, libraries, failure modes, and tooling. Switching to a Lisp-derived language does not extend that knowledge – it resets it. Clojure keeps the JVM underneath but discards almost everything a developer has learned about how to structure solutions idiomatically. The ten-year veteran spends their first six months feeling like a junior again. Recursion replaces loops. Immutable pipelines replace stateful objects. The mental models that took years to build are, at best, partially transferable. They might even fail entirely to transition to functional thinking, after decades in imperative and OOP styles. That cost and those risks are real and largely invisible in adoption discussions, and they fall on precisely the experienced developers an organisation most wants to retain. Knowledge compounds most effectively when it is built upon incrementally. Clojure does not permit that. It demands a clean break, and most organisations and most developers are not willing to pay that price.

The high wages Clojure commanded were not, from a management perspective, a straightforward mark of quality. They were a warning of risk, of "god programmer" lock-in. They reflected something less flattering than productivity: the classic dynamic of the expert who becomes indispensable by writing systems that only they can maintain. At its worst this approaches a form of institutional capture – a codebase so entangled with one person's idiom that replacing them becomes prohibitively expensive, something uncomfortably close to ransomware in its commercial effect.

That position has been further undermined by the rise of agentic coding tools. The practical value of writing in a mainstream language has dramatically increased, because AI coding assistants are trained on the accumulated body of code that exists – and that body is overwhelmingly Python, JavaScript, Java, and C#. The effect is concrete: ask a capable model to produce a complex data transformation in Python and it draws on an enormous foundation of high-quality examples. Ask it to do the same in idiomatic Clojure and the results are less reliable, the suggestions thinner, the tooling shallower. It might have to go through several rounds of trial-and-error. A language's effective learnability in 2026 is no longer a matter only of human cognition; it is also a function of training density. Niche languages are niche in the training data too, and that gap compounds. The expert moat – already questionable on organisational grounds – is being drained from two directions at once.

Clojure's ideas spread widely and rapidly through the languages that absorbed them and left the parentheses behind. Its practitioners, once among the best-paid developers in the industry, now find that the scarcity premium they commanded rested partly on barriers that no longer hold.

So, just what is Clojure, anyway? It is a language that was correct about the most important questions in software design, arrived a decade before the industry was ready to hear the answers, and expressed those answers in a notation the industry was not willing to learn.

The language was right about the future of programming. It might not be part of that future now that it has arrived. But it rightly deserves a place in computing history.

This article is part of an ongoing series examining what programming languages actually are and why they matter.

Language	Argument
C	The irreplaceable foundation
Python	The approachable language
Rust	Safe systems programming
Clojure	Powerful ideas, niche language

Coming next: Zig, Odin, and Nim – three languages that think C's job could be done better, and have very different ideas about how.

Just What IS Rust, Anyway?

Dimension AI Technologies — Sat, 07 Mar 2026 17:20:42 +0000

Any why does everyone say it's hard?

Every mainstream language fits a mental slot. C is a systems language. Python is a runtime ecosystem that excels at orchestration. JavaScript is a browser language that escaped into the server.

Not quite: Rust doesn't fit the usual slots.

Where Python is hard to classify because it does so many things loosely, Rust is hard to classify because by contrast it does one thing with unusual rigour.

Developers who haven't used it have heard the same three adjectives: fast, safe, and difficult. That specific combination is not at all accidental; it is in fact fully intentional. Understanding why those three things travel together is the key to understanding what Rust actually is.

The first article in this series argued that C's importance derives not from the language itself but from the ABI — the universal binary interface that every other language targets at its boundaries. It dominates, half a century on, through network effects - like how the English became the world's language.

The second in this series, argued that Python is best understood as a runtime ecosystem (alongside .NET and the JVM) rather than a language with a clean output artefact.

This third article explores how Rust sits at the intersection of both arguments. It is a systems language that takes the C ABI seriously, and its design is most clearly understood once that context is established.

The problem Rust was built to solve

The dominant categories of serious software vulnerability — buffer overflows, use-after-free, dangling pointers, data races — are not programming errors in the usual sense. They are permitted operations in C and C++. The language allows them. The programmer is the last line of defence, and programmers are not reliable at scale.

This is not a minor concern. Microsoft disclosed in 2019 that roughly 70% of the CVEs it addressed in the preceding decade were memory safety issues. Google reported similar figures for the Chrome codebase. These are not exotic edge cases; they are the default failure mode of systems written in C and C++.

Languages that solved this earlier — Java, C#, Go — did so with garbage collectors and managed runtimes. That works, but the cost is real: non-deterministic pauses, memory overhead, and loss of control over how data is laid out. For application development those costs are usually acceptable. For kernels, databases, real-time systems, and network infrastructure they frequently are not.

Approach	Examples	Cost of safety
Human discipline	C, C++	Vulnerabilities (CVEs)
Runtime (GC / interpreter)	Python, Java, C#, Go	Latency and memory overhead
Static analysis (type system)	Rust	Development time and compile time

Rust proposes that the third row is achievable: memory safety enforced by the compiler, with no garbage collector, no managed runtime, and no runtime cost. The question is what that actually requires.

The organising insight: correctness moves into the type system

Every language makes a choice about when to catch errors. Dynamic languages catch them at runtime — when the programme is already running. Statically typed compiled languages catch type errors at compile time. Rust extends this principle as far as it can be extended: memory safety, aliasing rules, and concurrency correctness are all encoded in the type system and verified before the programme runs.

This is not merely a technical decision. It represents a different understanding of what a compiler is for. In most languages, the compiler translates code that looks correct into code that runs. In Rust, the compiler's job includes refusing to translate code that could behave incorrectly at runtime — even if the same code would compile without complaint in C or C++.

The Rust compiler is therefore closer in spirit to a formal verification tool than to a conventional translator. Ownership, borrowing, and lifetimes are not quirks of the language's syntax or design accidents. They are the mechanism by which the type system reasons about memory at compile time.

The three mechanisms

Ownership

Every value in memory has exactly one owner at any given time. When ownership is transferred to another binding, the original becomes invalid. The compiler enforces this statically.

let s = String::from("hello");
let t = s;                      // ownership moves to t
println!("{}", s);              // compile error: s is no longer valid

This is not a runtime check. The compiler refuses to produce this programme. The consequence is that double-free errors become structurally impossible: if only one binding owns the memory, only one thing can free it, and that happens automatically when the owner goes out of scope.

Borrowing

Rather than transferring ownership, code can borrow temporary access to a value. Rust permits either multiple simultaneous read-only borrows, or a single read-write borrow — but never both at once.

let mut v = vec![1, 2, 3];
let r = &v;                     // immutable borrow begins here
v.push(4);                      // compile error: cannot mutate while borrowed
println!("{:?}", r);

This rule is the compile-time equivalent of a readers-writer lock. It eliminates data races before the programme runs: if the compiler can see that two threads could hold conflicting access to the same data, it refuses to compile the code. In an era where every server runs on multi-core hardware and concurrent execution is the norm rather than the exception, this guarantee matters. C requires the programmer to reason about thread safety manually. Python sidesteps the problem with the Global Interpreter Lock, which prevents true parallelism. Rust encodes the constraint in the type system and enforces it for free.

Lifetimes

The compiler tracks how long each reference remains valid. If a reference might outlive
the value it points to, the programme does not compile.

fn first_word(s: &str) -> &str {
    &s[..5]  // compiler verifies this reference cannot outlive s
}

Dangling pointers — references to memory that has already been freed — are structurally prevented. The compiler requires that the proof of safety be expressible in terms it can verify; if it cannot be expressed, the code does not compile.

Together, these three mechanisms mean that a Rust programme which compiles cannot exhibit the class of memory error that accounts for the majority of CVEs in C and C++ codebases. The bugs are not caught at runtime. They are made structurally unavailable.

Why Rust is difficult

The difficulty follows directly from the mechanisms above. Most languages ask the programmer to write code that runs. Rust asks the programmer to write code the compiler can prove is safe — and that proof must be expressed explicitly enough for a static analyser to verify it.

Developers trained in languages that hide memory management have never been required to reason about ownership, aliasing, or reference lifetimes. These concerns exist in every language; they are simply invisible. Rust makes them explicit and mandatory.

This reframing matters in practice. The borrow checker — the component of the compiler that enforces borrowing and lifetime rules — is a common source of frustration for new Rust programmers. Experienced Rust programmers tend to describe the same component as a collaborator. The difference is not in the tool; it is in whether the programmer understands the exchange being made. The difficulty is the price of the guarantee. Once code compiles, an entire class of runtime failure has been ruled out by construction.

Why Rust compiles slowly

Rust compiles slowly relative to most comparable languages - and this has a specific cause.

Most compilers translate code into bytecode or directly into assembler. Rust's compiler however also performs static analysis: it verifies ownership transfers, checks borrow constraints, validates lifetimes across the entire programme, and confirms the absence of data races — all before emitting assembler. This extra layer has no direct equivalent in C, Go, or Java compilation; and it is where the magic of Rust happens.

Language	Memory/concurrency checking at compile time
C / C++	None — left to the programmer
Go	Escape analysis (basic); race detector available at runtime
Java / C#	Null safety (partial); no memory ownership model
Rust	Ownership, borrows, lifetimes, and data races — all static

The compilation overhead is the upfront cost of eliminating the runtime memory and thread errors that C/C++ freely permit. Think of it as an extra round of proofreading: a Rust program that eventually runs has already been formally checked in ways that no other mainstream systems language provides.

More on Rust and C

The C article in this series argued that C's importance derives from the ABI — the binary interface that every language targets when it needs to call outside itself. Rust in the Linux kernel still speaks C at the boundary, building safer implementations behind a C-compatible façade.

We need to say more about that observation here, because it identifies what makes Rust different from every previous attempt at a memory-safe systems language.

Java and C# solve memory safety, but they require a managed runtime. That runtime sits between the language and the machine. It manages its own heap, controls its own memory, and cannot easily share ownership with C code. Calling a C library from Java requires a bridge — JNI — that is notoriously difficult and imposes overhead. The managed runtime is the reason these languages never became genuine C replacements in systems
programming: the boundary between the managed world and the unmanaged world is too expensive to cross.

Rust conversely has no managed runtime and no garbage collector. Its memory layout is directly controllable. It can call C code, and be called by C code, through the same ABI mechanism that all other languages use — but without a runtime in the middle.

extern "C" {
    fn strlen(s: *const u8) -> usize;  // calls a C function directly via the platform ABI
}

That single declaration is enough for Rust to call any C function with no marshalling layer and no overhead. The reverse is equally straightforward: a Rust library can expose a C-compatible interface and be consumed by Python, Ruby, Go, or any other language as though it were a C library.

Rust therefore occupies a position no other memory-safe language has held: it can replace C module-by-module, function-by-function, without replacing the interfaces that the rest of the system depends on - without either the errors that C/C++ permit or the cost of C# or Java's runtime and garbage collection. That is quite an achievement - hitherto never achieved by any other language.

The Linux kernel illustrates this in practice. Rust has been accepted into the kernel — first experimentally, then as a first-class language alongside C in December 2025 — and Rust modules interoperate with fifty years of existing C kernel code through C-compatible interfaces. Rust doesn't discard or compete with the C ABI: it was designed to work within it.

Where Rust is used

Operating systems, databases (TiKV, sled), web infrastructure (Cloudflare's core networking stack, Amazon's Firecracker virtualisation engine), embedded systems, and the Linux kernel. The common factor is consistent across all of them: memory safety without a managed runtime.

It is for these reasons that Stack Overflow's developer survey found Rust the most admired language for nine consecutive years, from 2015 to 2024. The gap between admiration and adoption has however been wide and consistent: developers recognise the value of the guarantees but find the onboarding cost high. That gap has been closing a little faster since roughly 2022, as tooling, documentation, and the Cargo package manager have matured, and as the consequences of decades of memory-unsafe systems code have become harder to ignore; but large amounts of C and C++ are not about to be rewritten in Rust any time soon.

What Rust actually is

Rust is a systems language that moved the programmer's memory discipline into the compiler. That single decision accounts for everything unusual about it: the strict type system, the slow compilation, the learning curve, the purported difficulty, and the guarantees.

The language is internally consistent once its central ambition is clear. The borrow checker is not arbitrary strictness; it is the mechanism by which ownership rules are enforced. The slow compilation is not a tooling failure; it is the cost of static analysis that other compilers do not perform. The new way of thinking is not poor design; it is the price of eliminating at compile time the errors that every other systems language discovers at runtime — or in a CVE report.

Rust is not a general-purpose language competing with Python or Go for application development. It is the first plausible answer, after fifty years, to the question of whether C-level performance and memory safety can coexist without a runtime or garbage collection. The answer, it turns out, is yes — provided the compiler is willing to do enough of the work, and the programmer is willing to let it. It is to C's credit that it took half a century for anyone to work this out. For all these reasons, Rust is an enormous advance, whose benefits are still in their infancy. Give it another 50 years to play out?

MVVM Made Easy

Dimension AI Technologies — Fri, 06 Mar 2026 16:58:35 +0000

The architectural pattern "Model-View-ViewModel" is now over 20 years old yet is still notoriously hard to understand.

A developer might implement INotifyPropertyChanged, wire up bindings, make controls respond to state changes and ship a working application. But if a colleague asked you to explain – not how MVVM works, but why it is structured the way it is – many developers with years of experience might give a detailed technical answer but be met with blank incomprehension. They know the plumbing but explaining the concept remains hard.

To be fair, to use MVVM you can get away with just knowing the how to use but still not understand why it came to be - or explain it simply.

Two things make MVVM genuinely hard to understand:

First, the name: "Model, View, ViewModel" describes the three components, not what they do, not how they relate, and not why the separation matters. It is like naming the parts of a car "Metal, Glass, Rubber" and expecting that to teach someone to drive.

Second, almost every tutorial leads with binding syntax and interface implementation – the hardest, most fiddly part of the pattern – before establishing the underlying idea. This is exactly backwards.

[A side-note on scale before going further. If you are binding a single text box to a string property, MVVM is pointless overhead. It is the kind of pattern that earns its complexity only when multiple views share the same data, react to each other's state and need to remain independently testable. If you are building a dashboard where changing one filter should re-query several data sets and update four panels simultaneously, MVVM is not over-engineered – it is the only approach that remains intelligible at maintenance time.]

Why MVVM exists

Let's start by elucidating what problem MVVM was introduced to solve, in three parts:

Testability. A ViewModel contains no UI framework code. It can be unit tested in isolation: no window instantiation, no simulated button clicks, no rendered elements to inspect. You call a method, you assert on state. The logic that drives your UI is testable in the same way any other class is testable. Before this, automated testing of UI's was hard if not impossible - and relied on expensive, grumpy humans.

Separation. The View is a dumb rendering surface and nothing more. Domain logic lives outside it. When you need to retarget the same underlying data to a different interface – a mobile layout, a web front end, a printed report – the ViewModel and Model are unchanged. The View is the only thing that needs to change. This makes cross-platform support (Windows/macOS/Linux, mobile/table/desktop) a cinch.

Binding engine compatibility. In declarative UI frameworks, the binding engine expects properties and observable state, not imperative UI code. A ViewModel is exactly the component that provides that interface. It is not incidental to the pattern; it is part of the reason the pattern takes the shape it does.

Without understanding these three drivers, MVVM might look like pointless ceremony.

A developer who already knows Model-View-Controller ("MVC") might reasonably ask: why not just put this logic in the View? The answer is:

because you cannot unit test a View
because tying domain logic to a UI framework makes it fragile and non-portable, and
because declarative binding engines need something to bind to.

The SQL analogy

The clearest route into MVVM for most developers is something they already understand: relational databases and SQL.

Think of the mapping like this:

Model = the database engine and its tables – the entire data and domain layer, including services and repositories. Not merely a DTO or a row; the full source of truth.
ViewModel = a parameterised SELECT statement plus the logic that drives it.
View = the rendered output of that query.

The forward direction is intuitive: data flows from the table, through the query, to the displayed result – exactly as it does in SQL Server Management Studio.

A qualification now needs making: a SELECT statement is stateless and declarative - it runs and gives output; whereas a ViewModel is stateful and procedural - it holds data in memory and can be updated. The SQL analogy thus holds for the shape of the relationship, not the implementation detail. A ViewModel also carries UI-only state that has no equivalent anywhere in the data layer – loading flags (IsBusy), selection state (IsSelected), temporary form edits, pagination position. The most accurate framing is that a ViewModel is a both the domain state plus UI interaction state, not merely a query.

What the SQL analogy does capture very well is the relationship between the three layers, and the point at which the analogy breaks is exactly the point at which MVVM becomes interesting.

In SQL Server Management Studio (or, indeed, any database query application), the result grid is read-only with respect to the underlying query. You can run a SELECT and see a result set; but if you want to edit the data, if the table permits it, you have to edit individual rows directly. But those edits do not change the query or cause another query to re-run. They do not update the results displayed in a different query window. For the updated data to percolate through to the viewable output, you have to run the SQL query again.

MVVM evolved to address all three of these issues.

Consider what it would mean if SQL Server Management Studio worked differently:

-- Query 1: you click "GROCERY STORES" in this result set
SELECT ProviderClass, COUNT(*), SUM(Amount)
FROM Entries
GROUP BY ProviderClass

-- Query 2: automatically re-runs, filtered by your selection
SELECT OurClass, COUNT(*), SUM(Amount)
FROM Entries
WHERE ProviderClass = 'GROCERY STORES'
GROUP BY OurClass

What if selecting a row in one result automatically re-executes another query with a WHERE clause derived from your selection? The two result sets would then react to each other. No database tool does this natively. This is precisely what MVVM, with its binding system, steps in to provide.

Under MVVM, the flow of information is bidirectional and looks like this:

Forward:  Model → ViewModel → View
Backward: View  → ViewModel → Model

The forward pass is the query and its output - like executing a query in SQL Server Management Studio. The backward pass is the new MVVM bit: the user reaches edits the rendered output (e.g. double click and edit a field) and any edit flows back - changing either the underlying data (in the database) or the parameters of the query itself.

The nearest database analogy for the full bidirectional picture is a materialised view with triggers: the view renders derived data, but user actions fire triggers that modify the underlying query parameters, which re-materialise all the other views. Databases do not natively do this. That gap is what MVVM fills.

A worked example

Abstract descriptions of data flow are easy to nod along to and hard to retain. A small end-to-end example makes both directions of the flow concrete.

Imagine a customer management screen with a region filter, a customer grid, an orders panel, and a summary panel.

The user selects "North" from the region filter (View interaction).
The ViewModel updates its SelectedRegion property and re-queries the Model. The customer grid updates to show only northern customers (forward pass).
The user clicks a customer row (View interaction).
The ViewModel sets SelectedCustomer and loads that customer's orders from the Model. The orders panel updates (forward pass triggered by backward selection).
The user clicks an order in the orders panel (View interaction).
The ViewModel writes the selected order back to the Model and recalculates the summary. The summary panel updates (full round trip).

Each step either writes state backward through the ViewModel to the Model, or reads updated state forward from the Model through the ViewModel to the View – often both within the same interaction. This is the case where MVVM earns its structure. At this scale, without the pattern, you are managing a web of manual event handlers and direct control references. With it, each layer has a single, defined responsibility.

Bindings and commands – the wiring, and where it goes wrong

Bindings and commands are the mechanism that automates the flow described above. Neither is part of the idea of MVVM; both are the entire implementation of it. This distinction matters because tutorials that begin with binding syntax, before the concept is established, guarantee the confusion described at the start of this article.

Bindings propagate data state changes between the ViewModel and the View automatically, in both directions. The reactive binding layer is the concept; the specific syntax varies by framework. MVVM applies to WPF, MAUI, Avalonia, SwiftUI, and reactive front-end frameworks alike – the pattern is the same, only the binding expression syntax differs. In WPF/XAML terms: INotifyPropertyChanged drives the forward pass, notifying the View when ViewModel properties change; UpdateSourceTrigger controls when the backward pass fires, pushing user edits back through the ViewModel to the Model.

Commands handle action flow rather than data flow. If a binding is a pipe for state, a command is a trigger for action. A button click does not write a property value back through the ViewModel; it fires a command. Commands are defined on the ViewModel – they live in the same layer as the observable properties – and are exposed to the View through bindings. The ICommand interface in .NET is the standard mechanism; other frameworks have direct equivalents.

Understanding both primitives before reading about either is the correct order. Bindings carry state. Commands carry intent. Together they constitute the entire backward pass.

Where things go wrong. Using XAML as the concrete example, the most common failure modes are these:

Silent path failure. A mistyped property name in a binding expression fails without a compiler error. The UI simply does not update. There is no exception; there is a runtime warning in the Output window, if you know to look for it and have the right diagnostic verbosity set. Developers accustomed to type-checked, compiled code find this genuinely jarring.
DataContext absent or late. If the DataContext is not set, or is set after bindings have already attempted to resolve, the binding has nothing to point at. Again, this fails silently.
Wrong binding direction. OneWay when TwoWay was needed, or vice versa. The data flows correctly in one direction and not at all in the other, which can look like a ViewModel bug when it is a binding configuration issue.
Incomplete INotifyPropertyChanged. If property change notification is missing for some properties, the forward pass fires inconsistently. Some controls update; others do not. Debugging this without understanding the mechanism is an exercise in frustration.

XAML binding expressions are terse and unforgiving. An expression such as {Binding SelectedRegion, UpdateSourceTrigger=PropertyChanged, Mode=TwoWay} is compact, but one wrong token causes the whole expression to fail at runtime without a compiler error. Getting bindings right is a skill that takes time to acquire, which is part of why MVVM has a reputation for being hard. The pattern itself is not hard. The implementation surface is genuinely fiddly.

Three other ways to think about it

The SQL analogy is perhaps the easiest for developers with a database background. The underlying pattern, however, is general enough to be seen in many other contexts.

Spreadsheet. Cell values are the Model, formulas are the ViewModel, and the displayed grid is the View. Edit a cell value and every formula that depends on it recalculates immediately; the display updates without any manual refresh. Edit a displayed value directly and it writes back to the underlying cell, propagating through all dependent formulas. This is perhaps the most widely encountered example of reactive bidirectional data flow in everyday computing.

Music mixing desk. The multitrack recording is the Model, each channel strip – EQ settings, gain, pan position – is a ViewModel, and the audio output is the View. Multiple ViewModels operate on the same Model simultaneously, and adjusting one channel affects the audible result of the others. Muting a channel (View interaction) changes the ViewModel state, which changes the output. This captures the multi-view reactive case: several independent lenses on the same underlying data, each influencing what the others produce.

Map application. Geographic data is the Model, the current zoom level, pan position, and active layer filters are the ViewModel, and the rendered map is the View. Panning or zooming (View interaction) updates coordinates and scale in the ViewModel, which re-renders the visible tiles. Switching to satellite view or adding a traffic overlay applies a different ViewModel to the same underlying Model. Multiple panels – street view, satellite, elevation – are multiple Views of the same data.

The table below maps all four analogies across the key dimensions.

Mental model	Model (the truth)	ViewModel (the lens)	View (the output)	Bidirectional element
SQL / database	Tables + data layer	Parameterised query + driving logic	Rendered result grid	Selecting output re-queries; edits can write back to table
Spreadsheet	Cell values	Formulas	Displayed grid	Editing a displayed value writes back to the cell; recalculates all dependents
Mixing desk	Multitrack recording	Channel strip settings (EQ, gain, pan)	Audio output	Adjusting a channel control updates the output; muting feeds back to change the mix
Map application	Geographic data	Zoom / pan / layer parameters	Rendered map	Panning or filtering updates ViewModel parameters, which re-renders all panels

The concept, then the plumbing

The reason MVVM takes years to click for many developers is straightforward: standard explanations describe the parts rather than the logic. Once the concept is in place – a source of truth, a lens that shapes and drives it, a rendered output through the lens, and the ability to reach back through the lens in both directions – the plumbing becomes interpretable. The binding expressions, the INotifyPropertyChanged implementations, the ICommand wiring: these are no longer arbitrary boilerplate. They are the mechanical realisation of a flow you already understand.

Get the concept first. The implementation follows. At that point, MVVM stops looking like ceremony and starts looking like a disciplined way to manage reactive UI state at scale.

Seven further mental models for MVVM – accounting ledger, kitchen, wardrobe, stock trading terminal, library catalogue, security camera control room, and orchestra conductor's score – are set out in the footnote below for readers who find alternative framings useful.

Appendix: seven additional mental models

Mental model	Model (the truth)	ViewModel (the lens)	View (the output)	Bidirectional element
Accounting ledger	Journal entries	Trial balance / P&L (different aggregations of the same transactions)	Printed reports	Post a correcting entry and all reports regenerate
Kitchen	Ingredients in the larder	Recipe (selects, transforms, and combines)	Plated dish	Head chef tasting and calling for more salt: a View-level judgement that modifies the ViewModel parameters
Wardrobe	All clothes owned	"What to wear today" (filtered by weather, occasion, and what is clean)	Mirror	Deciding in front of the mirror to swap the jacket writes a change back to the selection logic
Stock trading terminal	Market tick data	Watchlist with filters and calculated columns (P/E, % change, position size)	Screen display	Placing a buy order writes back through the ViewModel to the Model, updating the portfolio and all dependent calculations
Library catalogue	Books on the shelves	Search query with active filters	Results list	Reserving a book marks it unavailable in the Model, updating results visible to every other user
Security camera control room	Camera feeds	Operator's selection of which feeds appear on which monitors	Monitor wall	Switching a monitor feed updates the ViewModel; a camera going offline updates the Model, greying out that feed on all monitors
Orchestra conductor's score	Composed music	Conductor's interpretation (tempo, dynamics, section balance)	Sound the audience hears	Conductor adjusts in real time based on what they hear: a feedback loop from View back through ViewModel, changing the next forward pass

Something Big Is Happening: a Response

Dimension AI Technologies — Sat, 21 Feb 2026 16:13:06 +0000

A response to a viral essay – agreeing with the urgency, adding precision about what these systems are and what they are not. TL;DR at bottom.

I. Yes, Something Big Is Happening

Matt Shumer's excellent and thought-provoking article "Something Big Is Happening" captures something that many of us who work with AI daily rarely articulate: paid-tier "AI" models in early 2026 are qualitatively different from those of eighteen months ago; and the gap between what they can do and what is commonly thought they can do is wide and still widening.

Coding workflows have been transformed. Legal, financial, analytical and programming tasks that once took hours or even days now take minutes. Anyone who dismissed these tools after a brief encounter with free-tier ChatGPT in 2023 owes it to themselves to look again, because they'll find capability stunningly stronger than what they remember.

We share Shumer's view that something important is happening and that underestimation of it is widespread. Where we'd like to add some supporting perspective is on what, precisely, is happening — to help clarity and form emerge from the dust-cloud of early-stage change. We suggest that "cognitive automation is scaling rapidly" does not automatically mean "autonomous intelligence is emerging". This may sound like a technicality, grasping it will help shape predictions, policy and career decisions so deeply that it is difficult to identify any period in the past that wrought such fundamental change.

Our view is that this new wave of technology is a profound expansion of cognitive automation — possibly the most significant technology in human history. Understanding what that means matters for anyone making life-decisions: everyone.

II. A Framework For Understanding: Nine Ideas

Own account that augments Shumer's essay by identifying nine developments that, taken together, amount to a genuine transformation in what computers can do and what humans will need to do.

They fall into three groups:

An Interface Revolution: how computers and humans can now talk to each and what they can do with data.
Labour Reallocation: how the relationship between people and software is being restructured.
"The Great Levelling": an economic re-balancing where power has suddenly shifted and what this means for who can build what and where.

Group 1 – The Interface Revolution: What Computers Can Now Do

1. Computers have learned to speak human language. For sixty years, humans had to learn the languages of computers — programming languages, query syntax and command-line interfaces — to make them do useful work. But not everyone can be – or wants to be – a computer scientist. That relationship has now reversed: machines can now receive and produce natural human language and be functionally useful across a vast range of tasks. This sounds simple, but its consequences are enormous: it eliminates the cognitive burden of having to express your thoughts in computer code. This removes the translation layer that has, for over half a century, stood between human intent and machine execution.

2. Unstructured data has become operable. This may be the most consequential development of all, yet it receives surprisingly little public attention. The majority of the world's information is unstructured. It sits in formats that computers can store but cannot meaningfully process: documents, emails, PDFs, meeting transcripts, legal filings, medical records. This enormous corpus of knowledge has never been queryable by machine beyond simple word-matching or the limited tools of traditional Natural Language Processing, which delivered useful results in narrow domains but never achieved general operability over arbitrary text.

Large Language Models have upended this. You can now point a system at a body of unstructured text and ask questions on a pseudo-semantic basis — approximating an understanding of meaning and context, rather than merely matching keywords. The result is imperfect but genuinely transformative: legal discovery, regulatory compliance, financial due diligence and medical literature review are already being reshaped by the fact that machines can now read documents and do something useful with what they find. Much of the real economic value is already accumulating here — in the mundane task of making the world's information accessible to computation for the first time. We do not need true Artificial Intelligence for this to happen and to be enormously valuable.

3. The mechanical work of computing is being automated. Coding, configuration, diagnosis and debugging — the production layer of software development — are increasingly handled by machines. Tasks that would have occupied a developer for a full day now emerge in minutes, with quality that often requires minimal revision. This human time can be reallocated to areas where machines still can't match humans such as creativity and relationships. This sweeping change already extends well beyond the software industry, because code is the substrate of the digital world we all use. Faster, cheaper code production accelerates every domain that depends on software — which in 2026 means all of them.

Interlude: Why This Is Not How Human Intelligence Writes

Human writing is typically goal-directed: you begin a sentence with an intended point, maintain an argument, and aim toward an endpoint you can roughly see. You can revise mid-stream, but the act is guided by a plan, even if only a loose one.

An LLM does not work that way. It does not start a sentence knowing where the sentence will end, or start a paragraph holding an argument in mind and steering toward a conclusion. It generates one token at a time, conditioned on the text so far, with no privileged access to "what it is about to say" beyond whatever patterns are statistically activated by the current context.

This is hugely important, because it explains a recurring phenomenon: outputs that look like coherent argumentation can still drift, contradict themselves, or smuggle in unstated assumptions. The model is not "pursuing" a claim. It is producing locally plausible continuations that often resemble purposeful reasoning because it has learned the surface form of purposeful reasoning from human text.

Group 2 – Labour Reallocation: How This Changes the Relationship Between People and Software

4. The abstraction layer has moved up. Software engineering has a well-known framework called the V-Model of Testing: at the bottom, writing and unit-testing code; moving upward through integration, system design, requirements specification, and acceptance testing.

Historically, most computing professionals spent their time near the bottom, doing mechanical production work. And a lot of developers will say they actively dislike coding: it is cognitively difficult and requires long hours that are generally not compatible with family life. Many technologists find themselves moving away from hands-on coding somewhere in their 30s as a result.

Language models have promoted the entire profession upward. Human work increasingly sits at the upper levels — conceiving, specifying, designing, reviewing, testing, and accepting — while the translation of a clear specification into working software is automated. The human role is shifting from production to direction and judgment: a change in kind, rather than merely degree. It has also extended careers: technologists can continue supervising and reading code well beyond their thirties. And it is even bringing former programmers back into active service, to help with older languages such as COBOL or C++.

5. The barriers to entry have dropped, and the specification gap has narrowed sharply. When the barrier to producing working software drops from "years of training in programming languages" to "the ability to describe what you want in plain English," the pool of people who can participate expands enormously. A domain expert who understands a problem deeply can now build a working tool to address it, without learning Python or hiring a developer as intermediary. Being expert in computer systems architecture or the latest frameworks and libraries shifts from "must-have" to "nice-to-have".

This connects directly to one of the oldest problems in software: the gap between what the customer wants and what the developer builds. They often talk past each other. Requirements are written, discussed, revised, misinterpreted, built wrong, sent back, and revised again — round after round that often ends with something that technically matches the brief but misses the point entirely. It is rather like walking into a pub, ordering a pint of bitter, and having the barman hand you a glass of Chardonnay because, in his professional judgment, that's what you probably need.

This gap is now far cheaper to surface and close, because iteration is cheap. A domain expert can sit down with an AI tool and produce a working example directly: here is what I want, here is how it should behave, here is what it should look like. There is no intermediary to misunderstand, no ping-pong of specification documents that accumulate ambiguity with every round, no techies trying to understand the creatives. The person with the problem can illustrate the solution themselves, in concrete and testable form. The specification gap has always been one of the largest hidden costs in software — responsible for wasted effort, failed projects, and the pervasive frustration of receiving something other than what was asked for. Cheap, rapid prototyping has compressed it dramatically. There is a new risk to be honest about, though: we may be trading a translation gap for a wisdom gap. If the user is unskilled in logic or systems thinking, they may describe a solution that is precisely what they asked for but fundamentally broken in ways a human developer would have caught. The intermediary was sometimes also a sanity check. As the barriers drop, the need for clear thinking about what you actually want — and whether it makes sense — becomes more important, not less.

6. This will change who goes into computing. The shifts described in points 3 through 5, taken together, will attract different people with different skills into technology. The field is likely to become more diverse, more domain-expert-led, more creative, more experimental, and less reliant on traditional computer science training, as people with deep knowledge of law, medicine, finance, logistics, or education find they can build tools for their own domains directly. This long-tailing of talent and ideas is one of the most positive long-term consequences of the current wave of AI development, and another that is so far little discussed.

Group 3 – The Economic Re-Levelling: What This Means More Broadly

7. Enterprise capability is now available to everyone: the Great Levelling. For decades, complex software development — data integration, sophisticated analytics, multi-system workflows, automated testing and CI/CD — was the preserve of large corporations with dedicated IT departments and enterprise budgets. Small businesses could see what was possible, but the cost placed it out of reach. They were locked out of the technology revolution, noses pressed against the window.

That gap is now closing. The same AI tools reducing headcount in large engineering teams are simultaneously putting enterprise-grade capabilities into the hands of small businesses and indie developers, anywhere in the world, at a fraction of the former cost. A two-person consultancy can now build tools that would have required a dedicated team and a six-figure budget three years ago. A sole practitioner in a regional town has access to the same capabilities as a team of fifty in a City of London office. A mid-size manufacturer can implement in two weeks what an external consultant said might take two years.

This is also where an old economic observation may reassert itself: Jevons' Paradox. When the effective cost of a capability collapses, it does not necessarily reduce the amount of that capability used and often increases it. Cheaper computation produced vastly more computation; cheaper bandwidth produced vastly more bandwidth consumption; and they combined to create entirely new categories of activity – such as social media, streaming and today's AI explosion.

There is a related and underappreciated fact about computing more broadly. For over half a century, the price of computation per unit has fallen relentlessly, while the economic value created by computation has risen just as relentlessly. The cost per transistor, per floating-point operation, per gigabyte stored or transmitted has trended toward zero in real terms. Yet total spending on computing infrastructure — hardware, software, cloud services, data centres — has continued to rise.

Far from being a contradiction, instead this reflects a structural property of general-purpose technologies. If a capability becomes cheaper, it does not become less valuable; it becomes embedded in more processes, more industries, and more decisions. Electricity, telecommunications and computing are all following this pattern.

If AI reduces the marginal cost of producing software and analysis, we should not expect a shrinking of the digital economy. We should expect its further expansion. Lower unit prices and higher aggregate value can coexist for decades, provided the capability continues to unlock new domains of use.

If the barriers to coding fall far enough, we should not assume "less software" or "less enterprise IT". We should expect more: more internal tools, more automation, more bespoke workflows, more integrations, and more experimentation inside small firms that previously could not justify any of it. Capability becomes omnipresent – almost ambient – and usage expands to fill it.

We think of this as "The Great Levelling". If giant corporations need fewer developers, the talent freed up flows outward — to smaller firms, new ventures, and parts of the economy that have struggled to keep pace with technology. The transition will feel like a rupture at times, and we should be under no illusions about that. But the longer shift is toward something vastly more positive: a world where the ability to build powerful software is no longer gated by organisational scale or geography. When the cost of producing value drops by orders of magnitude, more of it gets produced and the risk of being wrong all but vanishes.

8. The combined effect is larger than any single prior computing development. Each development above is individually significant. Together, they represent a bigger shift than the personal computer, the database, email, the spreadsheet or the internet, considered individually.

We make this claim for a specific reason: natural language as a programming interface lowers the barrier to entry; unstructured data becoming operable unlocks the majority of the world's information; automated code production compresses delivery timescales; cheap prototyping closes the specification gap; and the levelling of capability between large and small firms redistributes who can build what. No single prior computing innovation did all of these things simultaneously. Acting in concert, these changes are reshaping the economics of knowledge work at a pace and scale that may rival or exceed the impact of the internet to date.

9. This is a revolution. Taken together, these nine developments form a transformation whose full scale we are only beginning to appreciate. Whether it ultimately surpasses the internet in economic impact remains to be seen — but the breadth of what is changing, and the speed at which it is changing, already has no precedent in the history of computing.

III. A Distinction Worth Making: Capability and Intention

There is a distinction that deserves more attention in the current public conversation about AI, because it clarifies a great deal: the difference between what these systems can do and what they are.

What the Architecture Actually Does

At their core, large language models predict the next token in a sequence, and they do this extraordinarily well — well enough to produce outputs that are, across many tasks, indistinguishable from competent human work.

The mechanism is statistical pattern-matching over vast quantities of human-generated text. During training, the model learns associations between language patterns — associations rich enough to capture something resembling understanding of meaning, style, argumentation, and domain knowledge. When the output looks like good legal reasoning, elegant code, or sound medical advice, it is drawing on these learned associations, and the results can be remarkable. But without that training on human-produced knowledge, they are themselves incapable of anything. They merely reflect us back at ourselves, albeit very cleverly.

The Syntax-Semantics Gap: Symbols vs. Reality

It is vital to remember that these models operate entirely within the realm of syntax: pure text. They have no understanding of what the text means. They are extraordinarily sophisticated at manipulating symbols — words, numbers and code — based on their statistical relationships to other symbols. These relationships have been defined by humans, not machines. They possess no "grounded" model of the physical or causal world. They are, in essence, merely shuffling paper.

If you ask an "AI" to describe the trajectory of a falling glass, it is unable to simulate gravity or calculate the structural integrity of the floor. It will merely predict the most likely words a human would use to describe that event. This means they lack what engineers call Causal Reasoning. Because they don't understand why things happen in the real world — only how people talk about them — they are prone to "hallucinations" that are syntactically perfect but physically or logically impossible. They don't even know if they're right or wrong.

How Modern Systems Create the Appearance of Intention

Modern AI systems layer additional capabilities on top of this base. Instruction tuning teaches the model to follow directions. Tool use lets it interact with search engines, code interpreters, and databases. Agent architectures decompose complex instructions into sub-tasks, execute them sequentially, evaluate intermediate results, and iterate. Evaluation feedback from human evaluators shapes the model's behaviour toward outputs that people judge to be helpful and accurate.

The result is behaviour that strongly resembles intentional action. When an agent receives a complex brief, breaks it into steps, executes each step, checks its own work, and revises its approach, the resemblance to purposeful human work is close enough that many might mistake it — understandably — for "judgment" and "taste."

This resemblance is worth acknowledging honestly. These systems behave as if they have goals, and for many practical purposes the distinction between "has a goal" and "behaves as if it has a goal" may seem immaterial. If the output is good, does it matter why? We should concede the functionalist point here: in terms of impact, a system that behaves with perfect agency is indistinguishable from one that possesses it. If an AI agent autonomously completes a week-long project, the economic and social consequences are the same whether or not there is "something it is like" (a "quale") to be that agent. The distinguishing between capability and intention is enormously important for understanding the source of risk and for designing governance — but it does not diminish the scale of disruption.

But three things are worth noting. First, many researchers working on long-horizon planning, robustness and grounded world-models view LLMs as incomplete foundations for AGI, even while acknowledging their economic impact. Second, we do not need true AI for these tools to be extremely useful. Third, performance is uneven: these systems can look astonishing on unfamiliar ground and mediocre on your home turf. People are typically greatly impressed by LLMs' pronouncements on unfamiliar topics, but mightily unimpressed by their output in subjects where the user is expert. We must use these tools carefully, without overstating what they are and without worrying that rapid task compression automatically implies near-term wholesale role deletion. We are still useful.

Where the Direction Comes From

The goals, evaluation criteria, and decisions about what to ask an AI to build next all originate with human researchers, human institutions, and human capital allocation. The system pursues whatever goal it has been given and, as of 2026, that goal itself always comes from outside: from a human, who has a need. LLMs, as of early 2026, are not capable of "self-generating thought" or "self-direction".

A thermostat maintains temperature — without wanting warmth. Evolution produces adaptation — without wanting survival. Gradient descent reduces loss — without wanting improvement. In each case there is directionality, optimisation, and behaviour that looks purposeful. Yet in each case the direction is supplied by the structure of the system, rather than by any internal experience of desire. The system has no awareness of what it is doing. It is entirely mechanical. But — and this is important — a thermostat connected to a global energy grid with a bug in its optimisation function can freeze a city without ever wanting to. Scale and connectivity transform the consequences of mechanical systems, even absent intention. The same applies here.

Current AI systems sit in this same category. They are extraordinarily capable optimisation engines but the optimisation they perform is directed by human choices: human instructions, human-designed reward functions, human-defined objectives. The direction they travel is, in every meaningful sense, set by us. Human needs, human life.

Calling this "lack of intention" does not mean the systems are harmless. It means the risks come from mis-specified objectives, misuse and institutional incentives rather than from spontaneous self-motivated behaviour. The danger is human error and human recklessness, not machine volition.

This Matters for the Future

If these systems were genuinely self-directing — choosing their own objectives and determining their own trajectory — then the future of AI would unfold according to its own logic, and exponential extrapolations about autonomous capability may apply.

But if the trajectory depends on continued human decisions about funding, energy infrastructure, regulation and research direction, then the future is fundamentally a story about human choices, subject to all the familiar constraints that shape every other technology. There is still a human hand on the tiller.

We should be candid, though, about the limits of that reassurance. A hand on the tiller matters less if the vessel is a supertanker that takes five miles to turn. Market pressure, military competition, the sunk-cost logic of trillion-dollar infrastructure investments, and the sheer speed at which AI accelerates its own development cycle all create structural momentum that may prove stronger than any individual act of steering. The intention may be ours, but the current is powerful, and it has its own dynamics. Saying "humans are in control" is true today. Whether it remains practically true if development velocity continues to increase depends on whether the machines do develop the capability for self-direction and self-generated thought.

We think the evidence strongly favours this second view, and we find this encouraging, because it means the outcome is ours to shape through policy, investment, and institutional design — something that we do, rather than something that will simply be done to us.

A Note on "AI Building Itself"

Shumer highlights OpenAI's statement that GPT-5.3 Codex "was instrumental in creating itself," and correctly identifies this as a pivotal moment. We'd offer a supporting insight.

In concrete terms, OpenAI's engineers used the model as a tool during its own development — to debug training runs, manage deployment, and diagnose test results. This is impressive and represents a genuine acceleration of research productivity.

We'd frame it as a sophisticated instance of bootstrapping — a practice that has existed in computing since the 1960s, where a tool is used to build the next version of itself. The C compiler has been compiled by earlier versions of itself for decades. Bootstrapping is recursive and creates a real productivity loop, but what it creates is accelerated human-directed development rather than autonomous self-improvement.

It's also related to the concept of "dogfooding" whereby developers of Windows at Microsoft were made to use the unfinished product they were building, to accelerate the ironing out of kinks. The developers both used and improved their own product.

These ideas are important because "AI creating itself" carries a strong implication of agency: of endogenous desire, decision-making and action. We offer this description to assist precision: human researchers used a powerful AI tool to accelerate the human-directed process of building the next AI system. That is a remarkable productivity story, and worth understanding on those terms. But it is not truly an AI creating itself. It is an AI being used as a tool to assist in creating itself, under human direction and supervision.

IV. Some Cautions About Prediction

We share the view that change is accelerating, and we think the direction of travel is clear. We'd offer some additional considerations that may help with forecasts.

Task Complexity Changes Character as It Grows

The METR data on AI task completion is genuinely impressive: from ten-minute tasks a year ago to five-hour expert-level tasks with recent models, with the doubling time apparently accelerating. This can be extrapolated forward: day-long tasks within a year, week-long within two, month-long projects within three.

We add that five-hour tasks and month-long projects differ qualitatively. A month-long project involves shifting requirements, stakeholder dynamics, ambiguity that can only be resolved through human conversation, political context within organisations and the maintenance of coherent purpose for longer than any current model's working memory (if it has any at all) by orders of magnitude. These are features of the task environment rather than the cognitive difficulty of the task itself, and they may respond to scaling in different and less predictable ways.

This is a reason for care rather than scepticism: progress may continue impressively, but along a different curve than straight-line extrapolation from bounded-task benchmarks suggests.

Institutional Dynamics Will Shape the Pace of Adoption

There is a recurring pattern in technology history: capability arrives suddenly but adoption, implementation and deployment take time, because they depend on institutional readiness. Institutions need to manage change carefully and to avoid discontinuities, preventing change at pace.

Regulatory frameworks for AI in high-stakes domains — medicine, law, finance — are being developed but remain immature. In particular, liability for AI-generated errors is legally unsettled; professional licensing regimes will take time to adapt. Organisational procurement, integration and change management are substantial even when the technology works perfectly. These factors suggest adoption will be uneven — faster in some sectors, much slower in others, and everywhere shaped by realities that operate on their own timescales regardless of how rapidly the models improve.

Task Compression and Role Elimination Are Different Things

Most knowledge-work roles are bundles of tasks. A lawyer's job includes reading documents, drafting arguments, advising clients, negotiating, managing staff, building relationships, exercising judgment in ambiguous situations, and bearing personal legal accountability. AI is becoming very good at some of these tasks — but the bundle includes components that are relationship-based, political and accountability-bearing in ways that do not give way to automation in any way that we can currently envision.

When some tasks are automated, the role changes rather than disappears: headcounts will be redistributed, required skills will shift and the value of remaining human contributions will be recalibrated. But we should acknowledge the tipping-point risk honestly: if AI absorbs enough of the task bundle — say, 70% or 80% of what a junior associate or analyst currently does — the remaining tasks (judgment, relationships, accountability) may not sustain the previous headcount or salary floor. Roles may persist in name while the number of people employed in them falls sharply. The distinction between "transformed" and "eliminated" is real, but it can be cold comfort to the people on the wrong side of a headcount reduction. We should all be prepared: virtually every knowledge-work role will be reshaped over the coming years, unevenly, by industry, organisation and jurisdiction – even if models do not improve any further, and even if we never reach true Artificial General Intelligence. These new tools are already powerful enough to bring vast changes. The picture will be messy and at times the narrative may reveal itself in unexpected ways. But that is how economic transformation has always looked from the inside. Revolutions are nerve-wracking and exhausting – but generally work themselves out.

V. What We Actually Believe

We believe this is the most significant expansion of cognitive automation in modern history and that the process has a long way yet to run. These systems are genuinely useful, increasingly capable and already changing the working reality of millions of knowledge workers. Anyone who has yet to engage with them seriously is leaving value and preparation time on the table – and maybe also themselves. Better to be at the table than on it.

We also believe what people insist on calling "AI" are best understood as powerful optimisation engines attached to human goals — operating within architectures designed by human engineers, trained on human-generated data and deployed according to human decisions. They are tools of extraordinary and growing sophistication and the direction they travel is set by us.

This means the future of AI is fundamentally a story about human choices — about funding, regulation, institutional design and the wisdom with which we integrate these tools into our economies. This perspective gives grounds for agency rather than fatalism because the outcome remains ours to shape.

Shumer's practical advice is largely sound and we echo much of it: learn these tools, experiment regularly, build financial resilience, help your children develop adaptability rather than optimising for career paths that may shift beneath them. We offer this addition to his counsel: cultivate the habit of asking, with precision, what these systems actually are and how they work. The better your mental model of the technology, the better your decisions about when to trust it, when to verify, when to delegate and when to insist on human judgment.

As a concrete operating model: work as if these tools are junior staff with amnesia and no accountability. Delegate to them freely — drafting, exploring, prototyping, triaging — but keep humans on the hook for correctness and responsibility. Verify what they produce. Treat their output as a first pass, not a final answer. (A fair caveat: the "amnesia" part of this metaphor is eroding. Context windows now reach millions of tokens, and retrieval-augmented architectures give models functional memory across long projects. The metaphor still holds for accountability — these systems have no stake in outcomes — but for continuity of context, the gap is narrowing fast. Adjust accordingly.) This is how the most effective practitioners already work with them, and it maps directly onto the capability-without-intention distinction: these systems will do exactly what you point them at, with impressive competence, but they have no stake in whether the result is right. You do.

VI. The New Moat: Competing After the Levelling

If the "Great Levelling" makes enterprise-grade technical capability a commodity, it raises a survival question for the individual and the firm: when everyone has access to the same "super-junior staff," what constitutes a competitive advantage?

When the cost of production trends toward zero, the value shifts entirely to the things that cannot be automated or replicated by statistical pattern-matching. We identify four "New Moats" that will define professional success in the post-levelling era.

1. The Human Premium: Accountability and Trust

In a world flooded with AI-generated content and code, provenance becomes a luxury good. A machine can produce a legal brief, but it cannot go to jail for it. It can suggest a medical diagnosis, but it cannot lose its license or feel the weight of a patient's life.

The new moat is verified human accountability. Clients will pay a premium not for the "work" (which is now cheap), but for the "signature" (which remains expensive). Success will belong to those who cultivate a reputation for being the "Adult in the Room" — the person who takes the risk, provides the guarantee, and stands behind the output.

2. High-Context Relationships and "Political" Intelligence

AI is excellent at solving puzzles but poor at navigating "politics" — the complex, unstated web of human incentives, egos, and history that governs every large organization.

Tacit Knowledge: Knowing what the CEO actually cares about, even when it contradicts the formal brief.

Stakeholder Synthesis: Convincing three different departments with conflicting interests to move in the same direction.
The new moat is the ability to operate in high-ambiguity human environments where the most important data isn't in the database, but in the subtext of a meeting or the "vibe" of a partnership.

3. Curation, Taste, and the "Editor-in-Chief" Mindset

When production is throttled by human effort, "more" is a strategy. When production is infinite and instant, "more" is noise.

As we move from a world of scarcity to a world of glut, the value shifts from the creator to the curator. The new moat is Taste — the ability to look at ten AI-generated variations of a product, a strategy, or a design and know which one will actually resonate with a human audience. We are moving from a world of "Content Creators" to a world of "Content Editors," where the primary skill is the discernment to say "no" to 99% of what the machine produces.

4. Integration and Systems Thinking

The Great Levelling provides everyone with powerful "Lego bricks," but it doesn't provide the manual for the castle.

As AI handles the mechanical tasks (writing the function, drafting the clause), the human role becomes the Architect. The new moat is Systems Thinking: the ability to see how disparate pieces of technology, law, and business logic fit together into a coherent whole. While the AI focuses on the task, the human must focus on the outcome. Those who can bridge the "Wisdom Gap" by understanding how a single automation might break a larger system will be the ones who lead.

Because AI lacks a model of the real world, it is fundamentally incapable of Systems Thinking. It can optimize a single line of code or a specific paragraph, but it cannot foresee the "ripple effects" that a change might have on a complex, interconnected system.

A model can suggest a brilliant tax-optimization strategy (symbolic manipulation), but it cannot intuitively grasp how that strategy might alienate a specific regulator or trigger a sequence of unintended legal consequences (causal reality). The new moat is the ability to bridge this World-Model Gap. Humans must provide the "grounding" — the intuitive understanding of how the digital output will collide with the messy, physical, and political reality of the world. The machine provides the parts; the human provides the Causal Architecture.

VII. Closing

Today's global conversation about AI enjoys no shortage of urgency, but it is largely driven by fear. The greatest fear of all is fear of the unknown; and AI currently holds that label. This can be addressed with more precision. Even if what we have today falls short of true artificial intelligence in the fullest sense, these technologies are real. The changes they are bringing to knowledge work are significant and accelerating, and will continue for the foreseeable future. We need to engage early and thoughtfully, in order to collectively shape outcomes rather than merely react to them.

Understand what these systems are: extraordinary tools for cognitive automation, directed by human purpose. Understand also that they have yet to become systems with genuine autonomy, goals and self-direction. Until that capability arrives, the gap between "here" and "yet to arrive" is where sensible preparation and constructive public conversation need to take place.

Something big is indeed happening. It deserves precision about what it is and what it is not.

TL;DR

Shumer is right: something big is happening.
It is the most significant expansion of cognitive automation in history — but not yet the emergence of true artificial intelligence.
Large language models do not plan, intend or "know where they are going." They generate one token at a time, producing locally plausible continuations that can resemble reasoning without being goal-directed cognition.
These systems have no goals, no intention and no self-direction. They are powerful optimisation engines whose direction is set entirely by human choices.
Unless and until that changes, the future remains shaped by funding, regulation, infrastructure and institutional decisions — not machine inevitability.
The barriers to building software and analysis have collapsed. Enterprise-grade capability is now available to small firms and sole practitioners.
When the cost of a general-purpose capability falls, usage tends to expand rather than contract. Computing's unit price has fallen for decades while its total economic value has risen. AI is likely to follow the same pattern.
Expect more software, more automation and more embedded computation — not less.
Learn these tools. Use them daily. Treat them as highly capable junior staff with limited memory and no accountability.
Keep humans on the hook for correctness, judgment and responsibility.
Engage seriously — and be precise about what this is: transformative automation, not yet Artificial General Intelligence.

Never heard of microcode? Nope, us neither. But it's really important.

Dimension AI Technologies — Fri, 30 Jan 2026 12:47:38 +0000

Imagine you've been programming since the 1980s. Maybe you were a bedroom coder on a ZX Spectrum, then had a career writing BASIC and then Visual BASIC before finally transitioning to C#. Or if you were in the USA, maybe you learned on an Apple II and then learned assembly, Pascal, C, C++ and everything that came after. Four decades of programming, three for a living.

If you are such a person you will likely have never heard the word "microcode".

From from being a confession of ignorance, our own surprise at never having heard of it is widespread. And many who've heard the term have never looked any further.

Most professional programmers – even very senior ones – do not know about microcode in any concrete sense, for the simple reason that most never needed to.

The reason is simple: microcode sits below the abstraction of assembler instructions, which is usually the limit of what programmers care about. If your good old ANSI C compiled to good-looking assembler, most people stopped looking any further. Microcode was designed to be invisible and - for decades - it succeeded.

That is now changing. Security vulnerabilities, performance limits and the sheer complexity of modern processors have forced microcode into view. If you write software in 2025, you probably still don't need to understand microcode in detail; but you should know it exists, what it does and why it suddenly matters.

What microcode actually is

Every CPU implements an Instruction Set Architecture (ISA) - the set of instructions that software can use. x86, ARM, RISC-V: these are ISAs. When you write assembly language, or when a compiler generates machine code, the result is a sequence of ISA instructions.

Microcode is the layer below.

Inside the CPU, some instructions are simple enough to execute directly in hardware. An integer addition, for instance, can be wired straight through: operands in, result out - done in a single cycle.

Other instructions are however more complex. They involve multiple internal steps, conditional behaviour, memory accesses, flag updates, and corner cases. Implementing all of that in pure hardware would be expensive and inflexible.

Microcode provides an alternative. Instead of hardwiring every instruction, the CPU contains a small internal control program that orchestrates the hardware for complex operations. When the CPU encounters a microcoded instruction, it fetches a sequence of micro-operations from an internal store and executes them in order.

Think of it as firmware for the instruction decoder. The ISA defines what the CPU promises to do. Microcode defines how it actually does it.

The extent of microcode use varies by architecture:

x86 relies heavily on microcode because its instruction set is large, irregular and burdened with decades of backward compatibility.
ARM cores vary widely – many are predominantly hardwired, while high-performance implementations such as Apple's M-series or ARM's Cortex-X designs use microcode-like structures to varying degrees.
RISC-V implementations tend toward hardwired control, though complex extensions may introduce microcode.

Why microcode exists

Microcode originated in the 1950s as a way to simplify CPU design. Rather than creating custom hardware for every instruction, engineers could write microcode sequences that reused a common datapath. This made CPUs cheaper to design, easier to debug and simpler (and therefore cheaper) to modify.

By the 1960s, microcode had become central to computer architecture. IBM's System/360, launched in 1964, used microcode extensively. This allowed IBM to sell machines with different performance characteristics – different hardware implementations – while maintaining a single ISA across the product line. Software written for one System/360 model would run on another. Microcode made that possible. It was a big deal.

The pattern persists. x86 has survived for over forty years partly because microcode allows Intel and AMD to implement the same ancient instructions on radically different internal architectures. The 8086 of 1978 and a modern Zen 5 core both execute REP MOVSB. The microcode behind that instruction has been rewritten many times.

Modern microcode also serves as a post-silicon patching mechanism. Once a chip is fabricated, the silicon cannot be changed; but microcode can be updated. Operating systems and firmware routinely load microcode patches at boot time to fix bugs, close security holes and adjust behaviour. The physical chip stays the same; the control logic changes.

A concrete example

Consider the x86 instruction REP MOVSB. In assembly, it looks like a single operation:

REP MOVSB

The architectural specification says: copy ECX bytes from the address in RSI to the address in RDI, incrementing both pointers and decrementing ECX with each byte, until ECX reaches zero.

That is a lot of work for "one instruction." Internally, it involves:

Loading a byte from memory
Storing it to a different memory location
Incrementing RSI
Incrementing RDI
Decrementing ECX
Checking whether ECX is zero
Branching back if not

None of this is visible at the ISA level. The programmer sees one instruction. The CPU sees a microcode sequence, something like:

loop:
  load byte from [RSI]
  store byte to [RDI]
  RSI++
  RDI++
  ECX--
  if ECX != 0, jump loop

Modern implementations are more sophisticated – they may copy multiple bytes per iteration, use vector registers, or special-case aligned transfers – but the principle holds. Microcode makes the architectural fiction of "one instruction" hold together.

Why most programmers never encountered it

If microcode has existed since the 1950s, why have most programmers never heard of it?

Three reasons.

First, microcode place in the abstraction stack is quite awkward. Programming education typically covers high-level languages, then perhaps assembly, then maybe pipelines, caches and branch prediction. Microcode sits below the ISA but above transistors – a layer that courses tend to mention briefly, if at all, then move past.

Second, microcode is intentionally invisible. CPU vendors treat it as proprietary. Intel and AMD do not publish microcode documentation. You cannot call microcode from software. You cannot observe it in a debugger. You cannot disassemble it (legally, at least). If something is undocumented, inaccessible and unobservable, it tends to disappear from working knowledge. It's low level of recognition is a sign of success.

Third, for most of computing history, microcode simply did not matter for application programming. Performance problems were algorithmic and bugs were logical. Portability issues lived in languages and operating systems. The hardware was a black box that honoured its documented interface and that was sufficient.

Microcode only intrudes when:

Instructions misbehave in ways the ISA does not explain
Timing side-channels reveal internal implementation details
A "hardware bug" gets fixed by a "software update"

For most programmers, those situations never arose.

Historical irony

Here is an odd fact: microcode was more widely discussed in the 1960s and 1970s than in the 1990s and 2000s.

IBM's System/360 made microcode famous. DEC used it heavily in the PDP-11 and VAX lines. Some machines – Xerox Alto, certain Burroughs systems – even exposed writable microcode, allowing users to define new instructions. Dangerous, but fascinating. Malware authors can only dream.

Then the RISC (Reduced Instruction Set Computing) revolution promised simpler computing due to simpler instructions, executed faster, that would outperform complex microcoded instructions. The slogan was "hardwire everything." Microcode was subjected to name-calling as a relic of the CISC (Complex Instruction Set Computing) past.

Despite the name-calling, there was genuine engineering reality. Early RISC machines – MIPS, SPARC, early ARM – were indeed largely hardwired and performance improved. The argument seemed vindicated.

But x86 survived. Intel and AMD responded not by abandoning microcode but by hiding it more effectively. Modern x86 chips translate complex ISA instructions into internal micro-operations, execute those out of order across multiple pipelines and present the illusion of sequential execution. The microcode is still there. It is just buried under so many layers of complexity that even CPU architects sometimes struggle to explain exactly what is happening.

Meanwhile, the 1980s home computer generation – people who learned on the ZX Spectrum, Commodore 64, BBC Micro, Apple II – grew up with machines that were either hardwired (the 6502) or used microcode invisibly (the Z80). The 6502 famously had no microcode at all; its control logic was hand-drawn. The Z80 did use microcode internally, but this was entirely invisible to programmers and irrelevant to how you wrote software. Either way, there was nothing to notice so nothing to know about.

A whole generation of programmers came up without ever needing to know.

Why microcode matters again

In January 2018, the Spectre and Meltdown vulnerabilities became public. Not at all software bugs, these were flaws in how modern CPUs speculatively execute instructions – flaws that allowed attackers to read memory they should not have been able to access.

The response involved operating system patches, compiler changes and – famously – microcode updates.

Intel, AMD and ARM shipped new microcode that:

Modified branch prediction behaviour
Inserted serialisation barriers
Changed how speculative execution interacts with memory protection

Without changing the silicon of chips that were already in computers around the world, the microcode was updated and behaviour changed.

This made microcode visible in a way it had not been for decades. "We fixed the CPU with a software update" is a sentence that only makes sense if you understand that CPU behaviour is partly defined by mutable control logic.

In the years after Spectre and Meltdown there were many more such incidents:

Foreshadow (L1 Terminal Fault)
MDS (Microarchitectural Data Sampling)
TAA (TSX Asynchronous Abort)
Retbleed
Downfall
Inception

Each required microcode mitigations; and each exposed ever more about the gap between architectural promises and microarchitectural reality.

What this says about modern computing

The traditional conception is that hardware is fixed and software is mutable. You design a chip, fabricate it and its behaviour is set. Software is written that runs on top and whose can be changed at will.

But the underlying reality is that microcode means a CPU is not a fixed hardware object. Its behaviour is affected in three ways:

Architectural: defined by the ISA specification
Microarchitectural: determined by the physical implementation
Policy-driven: controlled by microcode that can be updated

This continues the working model of mainframes from the 1960s – but its security implications are new: mutable microcode becomes an attack surface; and when it defines security boundaries, microcode bugs become security vulnerabilities.

CPU vendors now publish microcode updates regularly. Linux distributions ship them and Windows Update delivers them. Your BIOS may load them before the operating system even starts. The CPU you are using now is not quite the CPU you bought.

This naturally results out of complexity. Modern CPUs are so complex – billions of transistors, speculative execution, out-of-order pipelines, multiple cache levels, simultaneous multithreading – that getting everything right in silicon is perhaps now impossible. Microcode provides a route for fixes without unpopular hardware upgrades: a way to fix mistakes after the fact, to adjust trade-offs and to respond to threats that were not anticipated during design.

Reframing the original surprise

So if you have been programming for decades and only recently learned about microcode, that does not indicate a gap in your education or a failure of curiosity. It means that you worked above an abstraction boundary that abstraction mostly held.

This is how successful design manifests. Abstraction exists so that programmers can ignore lower layers. For most of computing history, ignoring microcode was the correct choice: it let you focus on problems that actually mattered for your work.

We are however now in a transition where hardware is not just mutable but patchable. Not fully – most programmers still do not need to understand microcode in detail – but enough that awareness matters.

Closing thoughts

Microcode was always there. For most of us, we did not need to know. Now, sometimes, we need to understand where "software" ends and "hardware" begins. That boundary is a little more porous than programmers came to believe, but for practical purposes it held. Security research, performance engineering, and the sheer complexity of modern processors have eroded it.

If you write software that cares about security, performance or correctness at the edges, you should know that:

The CPU is not a fixed machine; it runs updateable control code
Microcode updates can change behaviour in ways that affect your software
The ISA is a contract, but the implementation beneath it is mutable

The illusion of fixed ISA's is still useful. But there's a lot going on beneath it that you need.

Just what IS Python, anyway?

Dimension AI Technologies — Tue, 27 Jan 2026 08:38:33 +0000

A mental model for understanding Python's role

Every mainstream language fits a mental slot. C is a systems language. JavaScript is a browser language. Rust is a safety-focused systems language. SQL is a query language.

Python doesn't fit. It can be tricky, for an experienced programmer, to grasp what Python actually is and which slot to put it in. Often, they conclude "I don't like Python" and express confusion at its vast popularity in the 2020s.

Like the eponymous snake, Python can be hard to pin down — and like a real python, it may end up wrapped around your codebase whether you planned it or not.

A slippery language

Traditionally we're taught to classify languages along a few axes:

compiled vs interpreted
scripting vs "real" languages
imperative vs OO vs functional

Python fits poorly into all of them.

It isn't a compiled language in the C or Rust sense: it doesn't result in a standalone executable. It supports imperative, object-oriented and functional styles but isn't optimized for any of them. It began as a scripting language, but today it's used to build large, long-running systems.

So what IS Python?

The Key Insight: Python Is Not Defined by Its Output

The turning point is to realize that Python is not defined by the artefact it produces.

C, C++, Rust, Zig and Fortran produce binaries that can be directly run. The output is the thing. Once compiled, the language largely disappears from the execution model.

Python doesn't work like that.

A Python program needs a runtime ecosystem to execute: the interpreter, the object model, the garbage collector and the standard library. These are not incidental. They are Python. A Python program can't run standalone unless all of these components are bundled with it.

Python as a Runtime Ecosystem

In structural terms, Python sits alongside other runtime-centric language ecosystems:

C#, F#, VB.NET on .NET
Java, Scala, Kotlin, Clojure on the JVM

The similarity is architectural role: in all these cases, the runtime is the unit of execution, not any compiled artefact.

Strictly speaking, Python is a language specification with multiple implementations — IronPython runs on .NET, Jython on the JVM. But in practice, CPython and its C-API-dependent package ecosystem are Python. That's what made Python popular, and that's what we're discussing here.

The differences from .NET and the JVM matter too.

.NET and the JVM have JIT compilation to native code; CPython does not by default.
.NET and the JVM enforce static typing as part of the compilation model; Python's type hints are advisory.
.NET and the JVM produce native distributable artefacts (.dll, .jar) with stable ABIs (Application Binary Interfaces); Python does not, making it more difficult to call. Python prefers to call other libraries rather than be called itself.

So Python belongs in the "runtime ecosystem" category, but it's a looser, more dynamic variant; it trades static type-safe guarantees for flexibility and rapid development.

This structural similarity doesn't fully explain Python's success — Ruby, Perl and PHP share similar characteristics but declined while Python grew. Historical contingency matters: NumPy's timing, Google's investment in TensorFlow, and early academic adoption all played roles that had little to do with language design.

Where Python's Nature Is Clearest: Orchestration

Going to back to our question of "What IS Python?", the key is to realize that Python is a runtime-centric language. Its nature is clearest in numerical computing, data engineering and machine learning, where Python orchestrates work rather than performing it.

The most important Python libraries—NumPy, SciPy, Pandas, PyTorch, TensorFlow—are not written in Python in any meaningful sense. Python provides the API, the glue and the control flow. The heavy computation happens in C, C++, Fortran or CUDA libraries that expose a C ABI.

Python performs the same role over its libraries as:

SQL over databases
shell over Unix
VBA over Office

It is an orchestration language sitting above high-performance systems. That's why it thrives in scientific computing, data pipelines and machine learning. You build rapidly and easily, with simple syntax, while the underlying libraries deliver the performance. So long as orchestration overhead is low, Python-based systems can scale surprisingly far.

This is the glamorous use case — but not necessarily the most common one.

That's Not the Whole Story

The orchestration model explains Python's dominance in scientific and data-heavy domains — but most Python code written globally is web apps, scripts, automation and data munging where Python is doing the work directly.

In web development and business applications (think Django, Flask, FastAPI), Python handles HTTP requests, processes strings and executes business logic. Here, Python trades raw performance for development speed and ecosystem breadth. A Django application will be slower than an equivalent in Go or C#, but it may ship months earlier.

For these workloads, the framing is different: Python is a productive general-purpose language that prioritizes developer time over CPU time.

Why Python Succeeds

Python's popularity is no mystery once you consider this trade-off.

Being able to assemble things quickly, in readable code, with vast ecosystem support, matters more for mass adoption than type-safety, compilation speed or raw performance. Make something easy, and more people will do it; make something quick to do, and more people will do it, more often.

Python lowers the barrier to entry for proof-of-concept and prototype work. You can validate an idea in hours rather than days. If performance becomes critical later, you can translate hot paths into a compiled language—but you've already learned what needs building.

Getting something working at all, quickly, turns out to be more important than getting it working fast or elegantly. Shell scripting demonstrated this in the 1970s; Visual Basic and VBA did this in the 1990s; Python demonstrates it today. Make it easy and fast to build, and they will come and build.

A note of realism: "rewrite hot paths later" is technically true but economically rare. Most prototypes never get rewritten; they become production systems. This is true of any language, but Python's low barrier to entry means more prototypes get written in the first place — and more of them survive into production.

When Python Is the Wrong Choice

A fair assessment requires acknowledgement of where Python doesn't belong:

Hard real-time systems — Garbage collection pauses are unacceptable when deadlines are measured in microseconds.
Mobile applications — Neither iOS nor Android use Python as a first-class development language.
Browser code — JavaScript and WebAssembly own this space.
Memory-constrained embedded systems — Python's runtime overhead is prohibitive on microcontrollers (although MicroPython, a cut-down implementation, has some adoption in this space).
Latency-critical network services — Where every millisecond matters, Go, Rust or C++ are better choices.
CPU-bound pure-Python workloads — If you can't offload to native libraries, Python's interpreter speed becomes a genuine bottleneck.

These are domains Python doesn't seriously contest. More relevant are the pain points in domains where Python is used:

The GIL — The Global Interpreter Lock limits true parallelism in CPU-bound multithreaded code.
Packaging and distribution — pip, virtualenv, conda, poetry, and pyproject.toml represent years of fragmented solutions to dependency management.
Import system complexity — Relative imports, __init__.py behaviour, and module resolution remain sources of confusion.
Deployment — Shipping a Python application to end users without requiring them to install Python remains harder than it should be.

Python excels at orchestration, rapid prototyping and domains with strong library support. It is not a universal solution, and it carries real operational costs.

Why Python still feels slippery

Even with this framing, Python can still feel oddly unsatisfying if you come from strongly structured languages.

Compared with C#/Java or their ecosystems, Python has:

weak static guarantees
loose module boundaries
a simpler, leakier object model

If you're used to the discipline of C#, the functional elegance of F# or the precision of Rust, Python can feel vague. Things work — until they don't — and the language often declines to help you reason about correctness ahead of time.

That's a real cost. But as the previous section argues, for many problem domains it's a cost worth paying.

Clearing Up Misconceptions

"Python is slow."
True for CPU-bound pure-Python code. False when Python orchestrates native libraries—NumPy array operations execute at C speed regardless of Python's overhead.

"Python is a scripting language."
Historically accurate; Python originated as a scripting tool. But "scripting language" now undersells what Python has become.

"Python is interpreted."
Misleading. CPython compiles source to bytecode, then executes that bytecode on a virtual machine — much like many modern interpreters do. The distinction matters when reasoning about performance and behaviour, but it's an implementation detail rather than a defining characteristic.

A Better Language Taxonomy

Python fits comfortably into this three-tier classification:

Category	Examples	Defining Trait
Standalone native	C, C++, Rust, Zig, Fortran	The binary is the product
Runtime ecosystems	Python, Java, C#, F#	The runtime is the product
Host-bound scripting	Bash, PowerShell, VBA, Lua	The host environment is the product

Python belongs firmly in the second group—with the caveat that it's a more dynamic, less rigidly structured member than Java or C#.

The boundaries are not perfectly clean. Go has garbage collection, a runtime and reflection, yet produces statically-linked binaries — it sits at the boundary between the first two categories. Taxonomies are useful simplifications, not natural laws.

A brief note for Rust and Go proponents

A common challenge: Python's role is better served by "doing it properly" in a compiled language from the start.

That view makes sense if your problem is well-specified, stable, performance-critical and worth committing to upfront architectural constraints. In such cases, Rust or Go can be excellent choices.

But many real-world problems do not start that way. They begin as ill-defined, exploratory or fast-moving systems: data pipelines, research code, internal tools, integration glue. A research team needs to test an idea quickly at small scale. A business team needs a tactical solution because the problem won't wait for strategic architecture.

In those contexts, using a language with strict typing, memory models or concurrency primitives can frustrate development with language-wrestling, where making the language work becomes centre-stage.

Python and compiled languages are therefore not competitors but complements: Python for orchestration and discovery; Rust, Go or C# for stabilised, performance-critical components. Your Python prototype becomes your teacher—clarifying what the real system needs to do.

That said, Python's actual competition in most domains isn't Rust or Go — it's JavaScript/TypeScript, Ruby, R, and Julia. Python's victory over these closer competitors owes as much to ecosystem momentum and historical timing as to language design.

Summary

Python isn't confused, incoherent or a "toy" language. It simply departs from the mental models of earlier language generations.

Python is a runtime-centric ecosystem that excels at orchestration, rapid prototyping and leveraging high-performance native libraries. It trades static guarantees and raw speed for flexibility, readability and development velocity.

That trade-off turns out to be exactly what a large portion of programmers need — including many who aren't professional developers at all, but scientists, analysts and business users who need working code fast. It lets you deliver, quickly. And that's what makes Python incredibly useful — and wildly popular.

13 Languages Are Challenging C. Most Fail. Only Five Stack Up.

Dimension AI Technologies — Sat, 10 Jan 2026 13:02:17 +0000

Bjarne Stroustrup once observed:

"There are only two kinds of languages — the ones people complain about and the ones nobody uses."

No language exemplifies the first category as well as C.

So, are there any languages that are better?

That's an interesting question, but it's not the one worth answering.

The better question is:

Which languages can occupy C's position in the software stack?

The reason: C is far more than just a syntax. It is the binary and organisational substrate of modern computing. Every kernel, every runtime, every Python module, every shared library — they all pass through C at some point.

So "replacing C" means replacing that role, not just writing nicer code.

This essay examines C against thirteen "challenger" languages that are known — by their communities or by observers — as C-adjacent, low-level or C successor candidates.

We applied a systematic methodology using five filters to identify which ones are genuinely competing for C's throne — and which ones are solving different problems entirely.

What C actually is

C has been reigning champ of low-level procedural programming for over 50 years. You can think of it as having an alias-centric memory model — a metaphor, not a formal model, but a useful one.

Its defining axiom can be paraphrased as:

Memory is bytes; pointers alias; mutation is unrestricted.

Everything else follows from that.

By default, the compiler cannot assume pointer targets are unaliased unless explicitly told or able to infer it:

Unrestricted mutation becomes dangerous in the presence of aliasing;
Undefined behaviour is a constant hazard the programmer must actively avoid; and
Concurrency requires explicit synchronisation.

(For instance, memcpy assumes non-overlapping buffers; memmove does not. The distinction exists because unrestricted aliasing is the default.)

C's power comes from unrestricted aliasing; but so does its fragility.

C is nonetheless:

The ABI lingua franca
The OS interface
The library boundary
The toolchain anchor

C is the dangerous uncle everyone still invites to dinner — because he owns the house.

The "C-family" illusion

What we call the "C family" is really:

A shared grammar sitting on top of incompatible execution models.

C-family syntax means braces, semicolons, infix operators, if (…), for (…), while (…), and block-scoped variables. These define a parser-level classification but not a semantic one.

Java, Rust, Zig, Go and C# look related because their keywords, braces and semicolons are so similar. But they are not related at the level that counts: aliasing, lifetime and memory ownership.

The economic reason is simple: C syntax is the QWERTY keyboard of programming. Changing it raises training cost without improving machine-level behaviour.

C syntax won; C semantics didn't. Every major descendant kept the braces but rewrote the rules underneath.

This is why these languages attract endless argument: they sit on real fault lines (memory, aliasing and lifetime) and we can't avoid paying the costs. As Stroustrup's observation implies, the complaints are evidence of relevance — languages that matter enough to argue about.

The four real semantic families

Once you strip syntax away, all C-inspired languages fall into four execution models, defined by who controls memory and aliasing.

Model	Who owns memory?	Who enforces safety?	Examples
Unmanaged	Programmer	Nobody	C, C++, Zig, Odin, Hare, C3, Carbon, Jai
Hybrid	Programmer + runtime	Partial	D, Nim, V, Swift
Managed	Runtime	GC	Go
Verified	Compiler	Type system	Rust

(Languages like Java, C#, and JavaScript also fall into the Managed category, but they don't claim to be C replacements, so we exclude them from this analysis.)

Important caveat: These buckets are coarse. They describe the default execution model, not every possible subset mode. D in -betterC mode behaves differently from idiomatic D; Swift in Embedded mode behaves differently from standard Swift. The taxonomy captures where each language's gravity pulls you, not where heroic effort can push you.

The five filters a real C-successor must pass

A language must be able to:

Filter	Why
Freestanding compilation	Kernels, firmware, runtimes — code that runs with no OS beneath it
Deterministic layout	Structs and ABI are contracts
Stable C interop	The world is already written
No mandatory runtime	You must own the process
Toolchain-level visibility	Debuggers, profilers, sanitizers

Only a few languages can pass all of these filters.

Critical distinction: A language passes these filters if its default compilation mode meets them, or if a first-class, maintained mode exists that does. Languages requiring unofficial hacks, unmaintained forks, or heroic effort to achieve freestanding operation do not pass.

Scope note: This analysis evaluates languages positioned as C successors — that is, languages whose stated purpose or community framing includes replacing C in its substrate role. Languages that pass all five filters but are designed for different purposes (extending C, migrating from C++, or serving as C's companion) are excluded from the contender tiers. This is a scope choice based on stated intent, not a technical judgement.

The candidate pool

Here are the fourteen languages we'll evaluate. Each is discussed in public discourse as C-adjacent, low-level, or a potential C successor. Listed with core philosophy, semantic family, and a characterisation.

Language	Year	Philosophy	Semantic family	Characterisation
C	1972	"Trust the programmer"	Unmanaged	The dangerous uncle who owns the house
C++	1985	"Zero-cost abstractions"	Unmanaged	C's midlife crisis
Rust	2015	"Make invalid states unrepresentable"	Verified	Your compiler's disappointed parent
Zig	2016	"No hidden control flow, no hidden allocations"	Unmanaged	C's responsible older brother
Odin	2016	"The joy of programming, distilled"	Unmanaged	C for people who ship video games
Hare	2022	"Stability is a feature"	Unmanaged	C if Dennis Ritchie had a time machine
C3	2019	"Evolution, not revolution"	Unmanaged	C with a sensible haircut
D	2001	"C++ without the baggage"	Hybrid	The language that tried to please everyone
Nim	2008	"Write like Python, run like C"	Hybrid	Python wearing a C costume to a job interview
V	2019	"Simple, fast, done"	Hybrid	The language of bold promises
Swift	2014	"Safety without sacrifice"	Hybrid	Objective-C's attractive replacement
Go	2009	"Simplicity scales"	Managed	Java in a hoodie
Carbon	2022	"C++ migration path"	Unmanaged	Google's C++ apology letter
Jai	~2014	"Game programmers know best"	Unmanaged	The language equivalent of "coming soon"

C is the baseline. The other thirteen are the challengers.

Scope note: This analysis restricts itself to C-adjacent languages actively discussed as C successors in modern discourse. It excludes Ada/SPARK, Pascal variants, and other capable low-level languages that aren't typically framed as "C replacements" in contemporary conversation. Ada/SPARK in particular has decades of deployment in safety-critical domains (avionics, rail, defence) and would pass most of the filters below — its exclusion reflects contemporary framing, not capability. That's a scope choice, not a quality judgement.

The defining axioms

Each language can be summarised by what it believes about memory. But first, six definitions:

Memory: A flat array of addressable bytes. In C's model, any byte can be read or written if you have its address.
Pointer: A value that holds a memory address. Pointers let you indirectly access and modify data elsewhere in memory.
Aliasing: When two or more pointers refer to the same memory location. If p and q both point to address 0x1000, writing through p changes what q sees. This is powerful and dangerous.
Mutation: Changing the value stored at a memory location. Unrestricted mutation means any code with a pointer can modify that memory at any time.
Lifetime: The span during which a piece of memory is valid to access — from allocation to deallocation. In C, the programmer tracks lifetimes manually; use-after-free bugs occur when code accesses memory whose lifetime has ended.
Ownership: The responsibility for a piece of memory's lifecycle — who allocates it, who may access it, and who deallocates it. In C, ownership is a convention. In Rust, ownership is enforced by the compiler: every value has exactly one owner, and memory is freed when the owner goes out of scope.

C's defining axiom combines the first four: memory is bytes, pointers can alias freely, and mutation is unrestricted. Lifetimes and ownership are the programmer's problem. Every C-inspired language must decide whether to keep, constrain, or replace that axiom.

Language	Axiom
C	"Memory is bytes; pointers alias; mutation is unrestricted"
C++	"Memory is bytes; pointers alias; mutation is unrestricted; also here are 47 ways to abstract over that"
Rust	"Memory is owned; aliasing is controlled; mutation is permissioned"
Zig	"Memory is bytes; pointers alias; but we will tell you when you mess up"
Odin	"Memory is bytes; pointers alias; but the defaults should be sensible"
Hare	"Memory is bytes; pointers alias; but the language should be finished"
C3	"Memory is bytes; pointers alias; but the syntax shouldn't fight you"
D	"Memory is whatever you want it to be today"
Nim	"Memory is managed unless you insist otherwise"
V	"Memory is managed but we're working on making it optional"
Swift	"Memory is reference-counted; aliasing is... complicated"
Go	"Memory is the runtime's problem, not yours"
Carbon	"Memory is bytes; pointers alias; but we're fixing C++'s mistakes"
Jai	"Memory is bytes; pointers alias; and we'll ship when we ship"

The C-ness comparison

How close is each language to C's actual execution model?

Scoring rubric:

C-like syntax: Braces, semicolons, infix operators, familiar keywords
C-style pointers idiomatic: Pointer arithmetic, manual aliasing, and explicit address manipulation are normal usage patterns
Safety checks optional: Runtime bounds checking, null checks, and similar guards can be disabled or are off by default. (Note: Rust scores zero here because its safety is structural and compile-time, not a runtime check that can be toggled — this measures runtime check configurability, not overall safety philosophy.)
Manual control: Programmer controls allocation, layout, and teardown without runtime intervention

Star calibration:

⭐⭐⭐⭐⭐ = Indistinguishable from C in this dimension
⭐⭐⭐⭐☆ = Minor differences; C programmer would adapt quickly
⭐⭐⭐☆☆ = Recognisably similar but with significant divergence
⭐⭐☆☆☆ = Different default model; C-like usage possible but not idiomatic
⭐☆☆☆☆ = Fundamentally different approach
☆☆☆☆☆ = No meaningful similarity

Overall = minimum of the four columns. Rationale: a language is only as C-like as its weakest dimension. A language with perfect syntax but no pointer arithmetic cannot substitute for C in practice; the binding constraint dominates.

Language	Syntax	Pointers	Safety	Control	Overall
C	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
C++	⭐⭐⭐⭐⭐	⭐⭐⭐⭐☆	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐☆
Zig	⭐⭐⭐⭐☆	⭐⭐⭐⭐⭐	⭐⭐⭐⭐☆	⭐⭐⭐⭐⭐	⭐⭐⭐⭐☆
Odin	⭐⭐⭐⭐☆	⭐⭐⭐⭐⭐	⭐⭐⭐⭐☆	⭐⭐⭐⭐⭐	⭐⭐⭐⭐☆
Hare	⭐⭐⭐⭐☆	⭐⭐⭐⭐⭐	⭐⭐⭐⭐☆	⭐⭐⭐⭐⭐	⭐⭐⭐⭐☆
C3	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐☆	⭐⭐⭐⭐⭐	⭐⭐⭐⭐☆
Carbon	⭐⭐⭐⭐☆	⭐⭐⭐⭐☆	⭐⭐⭐⭐☆	⭐⭐⭐⭐☆	⭐⭐⭐⭐☆
Jai	⭐⭐⭐⭐☆	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐☆
D	⭐⭐⭐⭐☆	⭐⭐⭐☆☆	⭐⭐☆☆☆	⭐⭐⭐☆☆	⭐⭐☆☆☆
Nim	⭐⭐⭐☆☆	⭐⭐☆☆☆	⭐⭐☆☆☆	⭐⭐☆☆☆	⭐⭐☆☆☆
V	⭐⭐⭐⭐☆	⭐⭐☆☆☆	⭐⭐☆☆☆	⭐⭐☆☆☆	⭐⭐☆☆☆
Swift	⭐⭐⭐☆☆	⭐⭐☆☆☆	⭐☆☆☆☆	⭐⭐⭐☆☆	⭐☆☆☆☆
Rust	⭐⭐⭐⭐☆	☆☆☆☆☆	☆☆☆☆☆	⭐⭐⭐⭐☆	☆☆☆☆☆
Go	⭐⭐☆☆☆	☆☆☆☆☆	☆☆☆☆☆	⭐☆☆☆☆	☆☆☆☆☆

Key insight: Zig, Odin, Hare, C3, and Jai are C-family in physics. Rust is C-family only in grammar.

Note: C++ provides C ABI compatibility via extern "C" declarations, and this is how virtually all C++ libraries expose C-compatible interfaces. However, C++ cannot replace C at the ABI boundary: templates, overloads, and name-mangling have no C ABI representation, so the C++ features that distinguish it from C cannot cross that boundary.

How C-like languages diverged

Every descendant of C had to decide what to do about C's aliasing axiom. They took four different paths.

Path A — Keep C's physics

Languages: C++, Zig, Odin, Hare, C3, Carbon, Jai

They kept pointer aliasing, manual lifetimes, and undefined behaviour as a feature (or at least as an explicit tradeoff). They only changed ergonomics, not semantics.

These are C-family in physics.

(Some of these keep C's physics but still fail the five filters for non-technical reasons: maturity, release status, or scope. Carbon targets C++ migration; Jai isn't released. Semantic similarity doesn't guarantee practical usability as a C successor.)

Path B — Hide C's physics

Languages: Go (and outside our candidate pool: Java, C#, JavaScript)

They removed pointer arithmetic, explicit lifetimes, and alias control. They replaced them with tracing garbage collection, moving heaps, and runtime checks.

These are managed VMs with curly braces. They look like C but execute like Java.

Path C — Half-escape

Languages: D, Nim, V, Swift

They offer raw pointers when you ask, GC or ARC when you don't, plus slices and bounds checking. This creates two languages inside one compiler.

They are not C and not safe. They rely on discipline plus runtime support.

Path D — Replace the memory model

Languages: Rust

Rust throws away C's axiom — "Memory is bytes; pointers alias; mutation is unrestricted" — and replaces it with: "Memory is owned; aliasing is controlled; mutation is permissioned."

That is a new machine model, enforced at compile time.

Rust does not make C safer. It makes a different kind of machine that happens to use C syntax.

Applying the five filters

We now take all fourteen languages and run them through the five filters. C is the baseline — it passes by definition. The other thirteen are sorted into three tiers.

Tier 3: Clear failures

These languages have fundamental design conflicts with substrate programming, cannot be evaluated, or are explicitly designed for different purposes.

Go — "Simplicity scales"

Characterisation: Java in a hoodie

Go fails the "no mandatory runtime" and "freestanding" filters. It has a mandatory garbage collector, mandatory runtime scheduler, and goroutine stack management that requires runtime support.

This means Go cannot occupy C's substrate role. It can, however, occupy a different and valuable role.

The distinction means a lot:

Freestanding substrate programming = you control the machine (kernels, drivers, firmware, runtimes). No runtime beneath you.
Systems infrastructure programming = you build infrastructure software (containers, networking, CLI tools). Runtime handles memory and scheduling.

Go is excellent at systems infrastructure. Docker, Kubernetes, and countless networking tools prove this. But Go is structurally incapable of freestanding substrate work.

Illustrative example: Imagine a hardware interrupt with a ~10μs deadline. A garbage collector that might pause for milliseconds cannot coexist with that constraint. This isn't a criticism of Go — it's a category distinction. Go solves different problems.

Go replaces C in infrastructure. It does not compete for C's substrate role.

Carbon — "C++ migration path"

Characterisation: Google's C++ apology letter

Carbon's publicly stated focus is C++ interoperability and migration. It is not positioned as a freestanding substrate language today.

Carbon is a C++ successor, not a C successor. Different problem.

Jai — "Game programmers know best"

Characterisation: The language equivalent of "coming soon"

Not publicly released. No stable toolchain. Cannot be evaluated against filters.

C++ — "Zero-cost abstractions"

Characterisation: C's midlife crisis

C++ passes all five technical filters — it has freestanding mode, deterministic layout, full C interop via extern "C", optional runtime features, and complete toolchain support. However, C++ is explicitly designed to extend C, not replace it. Its stated philosophy ("zero-cost abstractions") is about adding capabilities above C, not providing an alternative substrate.

C++ is C's companion, not its successor. This is a scope exclusion based on the language's stated purpose, not a technical failure.

Tier 2: Conditional passes

These languages can pass the filters, but only when compiled in a restricted mode that disables significant features.

D (with -betterC) — "C++ without the baggage"

Characterisation: The language that tried to please everyone

BetterC mode removes the GC, runtime, classes, exceptions, dynamic arrays, associative arrays, nested functions with context, and most of the standard library (Phobos). What remains is closer to "C with templates" than idiomatic D.

D's tragedy is that it's genuinely well-designed, but arrived too early (before Rust proved the market) and tried to be too many things. In BetterC mode, C++ plus garbage collection becomes just C with better syntax.

Verdict: Passes filters, but the mode strips so much that it's debatable whether "D" is being used or a D-shaped subset.

Nim (with manual configuration) — "Write like Python, run like C"

Characterisation: Python wearing a C costume to a job interview

Nim can be pushed toward freestanding and embedded targets, but it becomes a "bring-your-own-runtime-stubs" exercise. Debugging largely happens at the generated-C level. The ABI is the underlying C compiler's, not Nim's.

Nim is better understood as a C producer than a C successor. It doesn't replace C; it generates it.

Verdict: Technically achievable. Philosophically awkward.

Swift (with Embedded Swift) — "Safety without sacrifice"

Characterisation: Objective-C's attractive replacement

Swift has an experimental Embedded Swift compilation mode that produces standalone object files with no runtime required. It disables reflection, existentials, and ABI stability. It primarily targets ARM and RISC-V embedded platforms.

This is genuinely interesting. But Embedded Swift is experimental, and Apple's priorities are phones, not kernels.

Verdict: Passes filters in experimental mode. Ecosystem and tooling are nascent. Worth monitoring.

V (with -gc none) — "Simple, fast, done"

Characterisation: The language of bold promises

V has a manual memory management mode and community members have built experimental kernel projects. But V's autofree — its main selling point — is experimental and not production-ready. The language is pre-1.0.

V promised a lot. The jury is still out on delivery.

Verdict: Technically passes. Maturity concerns.

Tier 1: Clear passes

These languages pass all five filters in their default or primary compilation mode. Their distinctive features remain available when targeting the substrate.

Rust — "Make invalid states unrepresentable"

Characterisation: Your compiler's disappointed parent

Axiom: "Memory is owned; aliasing is controlled; mutation is permissioned"

What it really is: A safe systems language wearing C syntax as a compatibility layer.

Rust's no_std mode is first-class. The borrow checker works without the standard library. In late 2024 and through 2025, Linux kernel maintainers progressively elevated Rust's status, with key maintainers publicly stating that Rust support is moving beyond experimental toward production use. (See LKML discussions and LWN coverage from this period.)

In safe Rust, the compiler enforces aliasing and lifetime rules that eliminate use-after-free and data races. This guarantee applies to safe code; unsafe blocks and FFI boundaries are the programmer's responsibility.

Trade-off: Borrow checker complexity. Steep learning curve. Interop with C requires unsafe blocks.

Zig — "No hidden control flow, no hidden allocations"

Characterisation: C's responsible older brother

Axiom: "Memory is bytes; pointers alias; but we will tell you when you mess up"

What it really is: C with a compiler that cares.

Zig has no runtime by default. It can replace not just C code but the C toolchain — it works as a drop-in C compiler and cross-compilation system. Comptime works without an OS.

Zig doesn't stop you shooting yourself in the foot. It hands you the gun with the safety on and a note explaining which end is dangerous.

Trade-off: Language still pre-1.0. API stability not guaranteed.

Odin — "The joy of programming, distilled"

Characterisation: C for people who ship video games

Axiom: "Memory is bytes; pointers alias; but the defaults should be sensible"

What it really is: Modernised C for large codebases.

Odin's freestanding target is first-class. The context system — Odin's mechanism for threading allocators and loggers through call stacks — works freestanding. Memory management is explicit.

Odin is what happens when someone who actually ships software designs a language, rather than someone who writes papers about shipping software.

Trade-off: Smaller ecosystem. Less tooling than Rust or Zig.

Hare — "Stability is a feature"

Characterisation: C if Dennis Ritchie had a time machine

Axiom: "Memory is bytes; pointers alias; but the language should be finished"

What it really is: What C might have been with hindsight.

Hare does not link to libc by default. It is designed explicitly for kernels, compilers, and system tools. The language specification will freeze at 1.0.

Hare's radical proposition: what if a programming language stopped changing?

Trade-off: Very early ecosystem. The project explicitly states support for Linux and FreeBSD only, on x86_64, aarch64, and riscv64 architectures. There is no intention to support proprietary platforms — this is a stated design choice, not an oversight.

C3 — "Evolution, not revolution"

Characterisation: C with a sensible haircut

Axiom: "Memory is bytes; pointers alias; but the syntax shouldn't fight you"

What it really is: C with obvious mistakes fixed.

C3 has full C ABI compatibility. You can mix C and C3 files in the same build with no friction. Contracts and slices work without libc. The compiler uses an LLVM backend.

C3 asks: what if we just... fixed the preprocessor and added slices? Sometimes the boring answer is correct.

Trade-off: Small community. Limited tooling. Pre-1.0.

Summary: The filter results

Language	Tier	C-ness	Outcome
C	Baseline	⭐⭐⭐⭐⭐	The thing we're trying to replace
Rust	1	☆☆☆☆☆	Clear pass
Zig	1	⭐⭐⭐⭐☆	Clear pass
Odin	1	⭐⭐⭐⭐☆	Clear pass
Hare	1	⭐⭐⭐⭐☆	Clear pass
C3	1	⭐⭐⭐⭐☆	Clear pass

D	2	⭐⭐☆☆☆	Conditional pass (-betterC)
Nim	2	⭐⭐☆☆☆	Conditional pass (manual configuration)
V	2	⭐⭐☆☆☆	Conditional pass (-gc none)
Swift	2	⭐☆☆☆☆	Conditional pass (Embedded Swift)

C++	3	⭐⭐⭐⭐☆	Excluded: companion to C, not successor (scope)
Go	3	☆☆☆☆☆	Clear fail: mandatory GC/runtime
Carbon	3	⭐⭐⭐⭐☆	Excluded: wrong target (C++ successor)
Jai	3	⭐⭐⭐⭐☆	Cannot evaluate: not released

Important distinction: The C-ness column measures semantic similarity to C's execution model. The tier column measures practical capability to occupy C's substrate role. These are independent axes. Rust scores zero on C-ness but passes all five substrate filters — it can replace C despite being nothing like it. Zig, Odin, Hare and C3 score high on both: they can replace C and feel familiar to C programmers.

Why the clear passes form the real contender set

The distinction between Tier 1 and Tier 2 is very important.

Tier 1 (Clear Pass) languages (Rust, Zig, Odin, Hare, C3) are designed such that their distinctive features remain available in freestanding mode.

Rust's borrow checker works without std
Zig's comptime works without an OS
Odin's context system works freestanding
Hare's tagged unions work in kernels
C3's contracts and slices work without libc

Tier 2 (Conditional Pass) languages (D, Nim, Swift, V) can target C's substrate position, but doing so requires abandoning the features that differentiate them from C.

D without GC is just C with nicer syntax
Nim without its runtime is just a C code generator
Swift without reflection is just... less Swift
V without autofree is still figuring out what it is

This is the meaningful distinction:

Which languages let you be productive in their idiom while targeting the substrate?

What each Tier 1 language is actually trying to fix about C

Language	Philosophy	C's failure it targets	Approach
Rust	"Make invalid states unrepresentable"	Memory safety	Compile-time ownership tracking
Zig	"No hidden control flow"	Implicit behaviour, toolchain complexity	Explicit allocators, drop-in C compiler
Odin	"The joy of programming"	Ergonomic scaling	Context system, better defaults
Hare	"Stability is a feature"	Undefined behaviour, language drift	Conservative redesign, frozen specification
C3	"Evolution, not revolution"	Preprocessor, weak type safety	Semantic macros, contracts, slices

This explains why they coexist: they disagree on what's wrong with C.

The real fault line

The true divide is not syntax. It is this:

Who controls memory?	Languages
Programmer	C, C++, Zig, Odin, Hare, C3, Carbon, Jai
Shared: Runtime + programmer	D, Nim, V, Swift
Compiler	Rust
Runtime	Go

Rust is the only language where the compiler enforces memory correctness for safe code.

Everyone else either:

Trusts you (Unmanaged) — "Here's a gun, try not to shoot your foot"
Hides memory from you (Managed) — "What gun? There is no gun"
Does both depending on mode (Hybrid) — "Here's a gun, but we've hidden most of the bullets"

Rust says: "You can have the gun, but I'm going to check your paperwork first, and also during, and also after."

The philosophical spectrum

The five Tier 1 contenders can be placed on two axes.

Axis 1: Compiler protection — how much should the compiler constrain you?

Maximum protection                              Minimum protection
        |                                               |
      Rust -------- C3 -------- Odin -------- Hare -------- Zig

Axis 2: Language complexity — how much machinery does the language have?

High complexity                                 Low complexity
        |                                               |
      Rust -------- Zig -------- C3 -------- Odin -------- Hare

The philosophies track these positions:

Language	Philosophy	Protection	Complexity	Personality
Rust	"Make invalid states unrepresentable"	Maximum	High	The perfectionist who won't ship until it's right
Zig	"No hidden control flow"	Minimum	Medium	The pragmatist who reads the assembly output
Odin	"The joy of programming"	Medium	Low	The game dev who's sick of fighting the language
Hare	"Stability is a feature"	Low	Minimal	The greybeard who remembers when C was new
C3	"Evolution, not revolution"	Medium	Low	The conservative who just wants C, but less annoying

The ecosystem reality

Language	Philosophy	Can replace C	Is replacing C	Where
Rust	"Make invalid states unrepresentable"	Yes	Yes	Linux kernel, Android, Windows components
Zig	"No hidden control flow"	Yes	Yes	Build toolchains, Bun runtime
Odin	"The joy of programming"	Yes	Partially	Game engines, developer tools
Hare	"Stability is a feature"	Yes	Not yet	Too early (released 2022)
C3	"Evolution, not revolution"	Yes	Not yet	Too early, small community

C does not get replaced in theory. It gets replaced by where people migrate their code.

What this analysis does not cover

This essay focuses on whether languages can occupy C's substrate role. It does not evaluate several practical factors that matter for adoption decisions:

Compilation speed — Zig and Odin emphasise fast compilation; Rust is notoriously slow
Corporate backing and sustainability — Rust (Mozilla origins, now independent foundation), Zig (foundation-backed), others vary
Migration costs and learning curves — Rust's borrow checker is steep; Zig and C3 are gentler for C programmers
Ecosystem maturity — Rust has crates.io; others have smaller package ecosystems

These factors may dominate practical language choice even when substrate capability is equal.

The real trajectory

C will not be "killed".

It will be:

Surrounded — Rust in Linux, Zig in toolchains
Absorbed — C3's C-mixing model
Constrained — new drivers in Rust, not C
Replaced in layers — userspace first, then kernel modules, then core kernel

Rust, Zig and Odin are already doing this. Hare and C3 show what a clean C could have been.

Conclusion

The story is not "C vs new languages".

It is:

Which languages can occupy the deepest layer of computing — the one C has held since 1973?

Fourteen languages were evaluated. Four failed outright, were excluded on scope, or couldn't be assessed. Four passed conditionally. Five passed cleanly. One is the baseline.

Each survivor has a philosophy and an axiom:

Language	Philosophy	Axiom
C	"Trust the programmer"	Memory is bytes; pointers alias; mutation is unrestricted
Rust	"Make invalid states unrepresentable"	Memory is owned; aliasing is controlled; mutation is permissioned
Zig	"No hidden control flow"	Memory is bytes; pointers alias; but we will tell you when you mess up
Odin	"The joy of programming"	Memory is bytes; pointers alias; but the defaults should be sensible
Hare	"Stability is a feature"	Memory is bytes; pointers alias; but the language should be finished
C3	"Evolution, not revolution"	Memory is bytes; pointers alias; but the syntax shouldn't fight you

The substrate is diversifying. Slowly, but measurably.

And the key insight:

Rust belongs to the C family only in grammar.
Zig, Odin, Hare and C3 belong to it in physics.

That is why Rust feels alien to C programmers, and Zig feels familiar.

They solve different problems; and that's why, as Stroustrup reminds us, people will complain about them for decades — because they matter.

Appendix A: Filter application detail

Language	Freestanding	Deterministic layout	C interop	No mandatory runtime	Toolchain visibility
C	✓	✓	✓	✓	✓
C++	✓	✓	✓ (via extern "C")	✓	✓
Rust	✓ (no_std)	✓ (repr(C))	✓	✓	✓
Zig	✓	✓	✓	✓	✓
Odin	✓	✓	✓	✓	✓
Hare	✓	✓	✓	✓	Partial (QBE backend)
C3	✓	✓	✓	✓	✓ (LLVM)
D	✓ (-betterC)	✓	✓	✓ (-betterC)	✓
Nim	✓ (manual)	Via C	Via C	✓ (manual)	Via C
V	✓ (-gc none)	Via C	Via C	✓ (-gc none)	Via C
Swift	✓ (Embedded)	Partial	Partial	✓ (Embedded)	Partial
Go	✗	✗	Partial (cgo)	✗	✓
Carbon	✗	✓	C++ focus	✗	✓
Jai	?	?	?	?	?

Appendix B: Complete language characterisation

Language	Philosophy	Characterisation	Semantic family	What it really is
C	"Trust the programmer"	The dangerous uncle who owns the house	Unmanaged	The alias-centric memory model
C++	"Zero-cost abstractions"	C's midlife crisis	Unmanaged	C with objects, templates, and regrets
Rust	"Make invalid states unrepresentable"	Your compiler's disappointed parent	Verified	A safe systems language wearing C syntax
Zig	"No hidden control flow"	C's responsible older brother	Unmanaged	C with a compiler that cares
Odin	"The joy of programming"	C for people who ship video games	Unmanaged	Modernised C for large codebases
Hare	"Stability is a feature"	C if Ritchie had a time machine	Unmanaged	What C might have been with hindsight
C3	"Evolution, not revolution"	C with a sensible haircut	Unmanaged	C with obvious mistakes fixed
D	"C++ without the baggage"	The language that tried to please everyone	Hybrid	C++ plus garbage collection
Nim	"Write like Python, run like C"	Python wearing a C costume	Hybrid	Python syntax on a C backend
V	"Simple, fast, done"	The language of bold promises	Hybrid	Fast-compile application language
Swift	"Safety without sacrifice"	Objective-C's attractive replacement	Hybrid	Apple's managed systems language
Go	"Simplicity scales"	Java in a hoodie	Managed	Systems infrastructure language, not substrate language
Carbon	"C++ migration path"	Google's C++ apology letter	Unmanaged	C++ interop successor
Jai	"Game programmers know best"	The language equivalent of "coming soon"	Unmanaged	Unknown (not released)

Appendix C: The four divergence paths from C

Path	What they did	Languages	Summary
A: Keep C's physics	Kept pointer aliasing, manual lifetimes, UB	C++, Zig, Odin, Hare, C3, Carbon, Jai	"C, but we fixed the obvious stuff"
B: Hide C's physics	Replaced with GC, moving heaps, runtime checks	Go	"What if we just... didn't let you touch memory?"
C: Half-escape	Raw pointers when asked, GC when not	D, Nim, V, Swift	"Have it both ways (and debug both sets of bugs)"
D: Replace the model	Static aliasing constraints, compiler verification	Rust	"What if the compiler was your mum?"

Appendix D: Freestanding substrate vs systems infrastructure

Freestanding substrate programming:

You control the machine
No runtime beneath you
You handle interrupts, memory maps, hardware registers
Examples: kernels, drivers, firmware, bootloaders, language runtimes

Systems infrastructure programming:

You build infrastructure software
Runtime handles memory, scheduling, I/O
You handle requests, processes, orchestration
Examples: containers, networking tools, build systems, CLI utilities

Architectural compatibility with hard real-time / ISR constraints:

Language	Compatible?	Notes
C	Yes	Reference implementation
C++	Yes	With care (no exceptions in ISR)
Rust	Yes	no_std mode
Zig	Yes	No runtime by default
Odin	Yes	Freestanding target
Hare	Yes	No libc by default
C3	Yes	LLVM freestanding
D (-betterC)	Likely	Requires restricted mode
Nim (freestanding)	Unclear	Depends on stub implementation
V (-gc none)	Unclear	Pre-1.0, limited evidence
Swift (Embedded)	Unclear	Experimental mode
Go	No	Mandatory GC/runtime
Carbon	Unclear	Not yet positioned for this
Jai	Unclear	Not released

Go is excellent at systems infrastructure. It is structurally incapable of freestanding substrate work.

ACKNOWLEDGEMENTS

Thanks to Paul J. Lucas for serving as technical language spec cop and pointing out an important correction.

Last updated: January 2026.

Why C is still the most important programming language

Dimension AI Technologies — Wed, 07 Jan 2026 13:03:09 +0000

Every programmer must learn it, even if they don't use it

Modern languages have replaced C in most application-level programming. Python dominates scripting and data science. Java and C# run enterprise systems. Go powers cloud infrastructure. Swift builds iOS applications. Rust is taking over systems programming.

Yet none of these languages has displaced C at the boundary.

When any of them needs to call a native library, talk to the operating system, or interoperate with code written in another language, it speaks C. Not because C is a good language – it has well-documented problems with memory safety and undefined behaviour – but because every platform defines the low-level rules for how compiled code communicates in terms of C.

Understanding why this is true, and what it means, is the reason every programmer should learn C.

ABI and FFI

When compiled code from one language calls compiled code from another, something must govern the mechanics of that call. Which CPU registers hold the arguments? Does the caller or the callee clean up the stack? How are structures laid out in memory? How are return values passed back?

These questions are answered by the Application Binary Interface, or ABI. The ABI is not defined by any programming language; it is defined by the platform. On Windows x64, Microsoft's calling convention applies. On Linux and macOS x64, the System V AMD64 ABI applies. On ARM64, the AArch64 ABI applies.

Every language that wants to call foreign code provides a Foreign Function Interface, or FFI. Python has ctypes and cffi. Rust has extern "C". Java has JNI. Zig has @cImport. The FFI handles language-level concerns: declaring signatures, marshalling strings, managing memory ownership. But when the call actually happens, the FFI must emit machine code that obeys the platform's ABI.

Here is the critical point: there is no single "C calling convention" that spans all platforms. Windows x64 differs from System V AMD64 differs from AArch64. But on every platform, the C compiler's calling convention becomes the platform's standard ABI. All other languages target that ABI when they need to interoperate.

ABI	Stable	Documented	Universal on its platform
Platform C ABI	✓	✓	✓
C++ ABI	Varies by compiler	Partially	✗
Rust ABI	Explicitly unstable	✗	✗
Swift ABI	✓ (since 2019)	✓	Apple platforms only

C++ ABIs differ between MSVC, GCC and Clang. Rust documents its ABI as unstable and reserves the right to change it. Swift's ABI is stable but was not designed for cross-language use.

The platform C ABI is the only binary interface that every compiler supports, every language runtime can target, and that has remained stable for decades. It works from assembly language with no runtime required.

The practical consequence: when you want to build a system spanning multiple languages – Rust for performance, Python for scripting, C# for business logic – every FFI involved will emit calls using that platform's C conventions. SQLite, OpenSSL, zlib, libgit2, LLVM, and thousands of other libraries expose C interfaces regardless of their implementation language, because the C ABI is the only interface all consumers share.

The operating system interface

The binary interface is not the only reason C remains central. The operating system itself is specified in C terms.

The Linux kernel is written in C. The Windows kernel is written in C. Darwin, the core of macOS and iOS, is written in C. FreeBSD, OpenBSD, and most embedded real-time operating systems are written in C.

More importantly, the portable operating system interface – POSIX – is specified as C function signatures and C types. File I/O, process management, signals, threads, memory mapping: all defined in terms that map directly to the platform's C ABI. This is not a philosophical choice about C's elegance; it is a practical choice about binary stability. C types are the lingua franca because the C ABI is the lingua franca.

Every language that wants to open a file, spawn a process, or allocate memory must ultimately call these interfaces. The call goes through the language's FFI, crosses into the platform's C ABI, and reaches the kernel.

The infrastructure that remains

An enormous amount of critical infrastructure is written in C and will remain written in C for the foreseeable future.

Linux, Git, curl, nginx, Apache, PostgreSQL, SQLite, OpenSSL, zlib, ffmpeg – foundational software that the modern internet depends on. These projects are actively maintained, and they are not being rewritten.

Someone must maintain this code, understand it when it breaks, fix the security vulnerabilities, diagnose the edge cases, and extend the functionality. That someone needs to read C fluently.

Even if you never contribute to these projects, you depend on them. Understanding the language they are written in helps you understand their behaviour, their limitations, and their failure modes.

The mental model

There is a secondary reason to learn C, less original but still valid: C forces you to confront the machine.

In C, memory is a flat array of bytes. Pointers are addresses. Allocation is explicit, and so is deallocation. There is no garbage collector, no hidden allocations behind convenient syntax. When you write malloc(100), you are responsible for those bytes.

A programmer who understands C understands what higher-level abstractions are hiding. They can reason about cache locality, memory layout, and the cost of indirection. When a Java program runs slowly or a Python script consumes unexpected memory, the programmer who learned C has a mental model for diagnosing the problem.

This is not the primary argument for learning C – the ABI argument is stronger and more specific – but it reinforces it.

What about Rust?

Rust and Zig are genuine competitors to C for new systems programming. They offer memory safety, better tooling, and modern language design.

In embedded and real-time domains – microcontrollers with 32 kilobytes of RAM, medical devices that cannot tolerate unpredictable latency, avionics and industrial control systems – C once had no competition. You needed a language that compiled to small, predictable, deterministic code with no garbage collector and no hidden runtime behaviour. Rust now offers this, with memory safety as well, and is a serious alternative.

More significantly, Rust has now been accepted into the Linux kernel. In December 2022, Linux 6.1 merged support for Rust as a second implementation language alongside C – and in December 2025, the kernel maintainers promoted Rust from experimental to a core part of the kernel. This is a genuinely epochal shift: for over 30 years, the Linux kernel was C and C alone. The decision to admit Rust, and then to make it a first-class citizen, reflects how seriously the kernel maintainers take its safety guarantees and how mature the language has become for systems work.

Even so, Rust in the kernel does not escape the C ABI. Rust kernel modules must interoperate with the vast existing C codebase through C-compatible interfaces. When a Rust library outside the kernel needs to be callable from Python, Go, C#, and Ruby, it exposes a C API. When Rust talks to the operating system, it uses C conventions. When Rust calls vendor SDKs, hardware abstraction layers, or existing libraries, it speaks C at the boundary.

Rust is not replacing C at the interface level; it is building safer implementations behind a C-compatible façade.

The only partial challengers

Two alternatives have attempted to displace the C ABI as the universal binary interface.

Criterion	C ABI	COM / WinRT	WebAssembly
Cross-platform	✓	Windows only	✓
Mature tooling	✓	✓	Limited
Native performance	✓	✓	Slower (5–30%)
No runtime required	✓	✗	✗
OS API access	Direct	Direct	Via host
Adoption in HPC / AI / scientific	Dominant	Rare	Emerging
Stable since	1970s	1993	2017

COM, and its modern descendant WinRT, provides a binary object interface with versioning and cross-language support on Windows. It remains Windows-only and is rarely used in high-performance computing, scientific computing, or AI infrastructure.

WebAssembly defines a portable binary format with its own ABI and is the first serious challenger in forty years. WASM today is slower than native code, however, tooling remains immature, and every operating system API still speaks C. WebAssembly may grow into a genuine alternative, but it has not done so yet.

Conclusion

Fifty years of programming language research have produced remarkable advances in safety, expressiveness, and developer experience. Modern languages are genuinely better than C for almost every application-level task.

Yet all of them, when they need to call outside themselves, target the C ABI.

This did not come about as a deliberate choice. C was simply there first, and by the time anyone thought to standardize cross-language interoperability, C's conventions were already embedded in every operating system, system library, and driver. In modern parlance: C gained network effects that make it extremely hard to dislodge.

The C ABI has thus become the binary equivalent of TCP/IP: a protocol everything else is built on, invisible until you look for it and impossible to escape once you do. Kernels are written in C; OS interfaces are specified in C types; critical infrastructure is maintained in C; and the ABI that connects everything is the C ABI.

You may never write a line of C. But if you write software that loads libraries, calls system APIs, embeds interpreters or links against native code, you are programming against the C ABI whether you know it or not.

That is why every programmer should learn it.

No, Clojure: your REPL is not new – or best

Dimension AI Technologies — Sat, 20 Dec 2025 11:07:34 +0000

Spend any time around Clojure's devoted community and you'll encounter a cluster of claims:

the Read–Eval–Print Loop ("REPL") is what makes Clojure fundamentally different (REPL – Wikipedia)
REPL-driven development supersedes the Edit–Compile–Run model typical of C-family, .NET and Java
Clojure enables a uniquely live, exploratory way of building systems
other languages "don't really have a REPL"

These claims sound radical, historically grounded and quietly superior, but they are – alas – more rhetoric than fact.

This article challenges established wisdom about Clojure in three areas:

the REPL long predates Clojure
Clojure neither invented nor uniquely exemplifies it
several alternative REPL models outperform Clojure's on important engineering criteria

To be clear, Clojure is a powerful language with dedicated supporters; so what follows is not an attack on Clojure, but a suggestion that its mythology needs a tweak.

The REPL long predates Clojure

Lisp had already established the model by 1958

The Read–Eval–Print Loop originates in Lisp systems developed at MIT in the late 1950s (History of Lisp – Wikipedia). From the outset, Lisp environments supported:

interactive evaluation
incremental definition of functions
inspection and modification of live runtime state
persistent sessions

The terminology itself has a long and well-documented history. The expression "read–eval–print cycle" is used by L. Peter Deutsch and Edmund Berkeley in a 1964 implementation of Lisp on the PDP-1 (Deutsch & Berkeley, 1964). Just one month later, Project MAC published a report by Joseph Weizenbaum — later known as the creator of ELIZA, the world's first chatbot — describing a REPL-based language, OPL-1, implemented in his Fortran-SLIP language on the Compatible Time Sharing System (CTSS) (Weizenbaum, 1964; CTSS – Wikipedia).

By 1974, the Maclisp Reference Manual by David A. Moon explicitly refers to a "read-eval-print loop" (page 89), even though the acronym "REPL" is not yet used (Moon, 1974).

From at least the early 1980s onward, the abbreviations REP loop and REPL are attested in the context of Scheme, where the term became standard (Scheme REPL terminology history).

Clojure deliberately situates itself within this lineage and explicitly inherits from it.

Once that inheritance is acknowledged, the oft-claimed notion that the REPL distinguishes Clojure needs correction. Any feature drawn wholesale from a sixty-year-old tradition cannot serve as a defining innovation.

ML: a typed REPL from the early 1970s

Alongside Lisp, the original ML language — developed in the early 1970s as part of the Edinburgh LCF project (LCF – Wikipedia) — was explicitly designed for interactive use.

ML's REPL supported incremental definition, immediate evaluation and full static type inference at the prompt. This was not an afterthought. ML was a metalanguage, intended to be explored live while retaining formal guarantees.

This matters because it shows that REPL-driven development under strong static typing is not a modern compromise or a reaction against Lisp. It is a parallel tradition, older than Clojure by decades.

Smalltalk pushed live systems further in the 1970s

Smalltalk systems went beyond REPL interaction and embraced image-based development (Smalltalk – Wikipedia), where the entire system existed as a continuously mutable artefact. Programs were edited while running; the notion of a clean restart receded into the background.

This approach predates Clojure by decades and represents a more radical commitment to liveness than Clojure's own model.

However one judges Smalltalk today, its existence alone undermines the idea that live, interactive programming is a modern breakthrough.

Home computers normalised persistent REPLs

The most consequential historical counterexample is neither Lisp nor Smalltalk. It is home computing.

From the late 1970s through the mid-1980s, the overwhelming majority of home computers booted directly into a persistent BASIC environment (BASIC – Wikipedia). Immediate mode was the primary interface. Variables survived RUN. Programs routinely relied on pre-initialised state in order to function within severe memory constraints.

This behaviour was universal and far from exceptional.

Home-computer BASIC: persistent REPL as the default interface

Machine	Year	BASIC variant	Persistent variables	Immediate mode
TRS-80 Model I	1977	Microsoft BASIC	Yes	Yes
Commodore PET	1977	Microsoft BASIC	Yes	Yes
Apple II	1977	Applesoft BASIC	Yes	Yes
Atari 400/800	1979	Atari BASIC	Yes	Yes
ZX-80	1980	Sinclair BASIC	Yes	Yes
VIC-20	1981	Commodore BASIC 2.0	Yes	Yes
ZX-81	1981	Sinclair BASIC	Yes	Yes
BBC Model A	1981	BBC BASIC	Yes	Yes
BBC Model B	1981	BBC BASIC	Yes	Yes
ZX Spectrum	1982	Sinclair BASIC	Yes	Yes
Commodore 64	1982	Commodore BASIC 2.0	Yes	Yes
Dragon 32/64	1982–83	Microsoft BASIC	Yes	Yes
Oric-1	1983	Oric Extended BASIC	Yes	Yes
Amstrad CPC	1984	Locomotive BASIC	Yes	Yes

Tens of millions of machines shipped with precisely this interaction model.

Rather than being an esoteric Lisp technique rediscovered decades later, the "tight feedback loop" was simply how personal computing worked for an entire generation. Many senior industry figures learned their craft in that world.

It is also worth noting that the BASIC world itself once abandoned the interactive model it had popularised. Early BASIC systems treated the programming environment as a live, persistent session. With the move to Visual Basic and later VB.NET (Visual Basic – Wikipedia; VB.NET – Wikipedia), that model gave way to an IDE-centred, project-based workflow, where code was edited, built and executed as a discrete artefact.

This shifted BASIC from language-as-environment to language-as-artifact.

Interactivity did not vanish entirely, but it moved from the language to the tooling, and the REPL ceased to be the organising centre.

Erlang demonstrated live code in production

To argue that Clojure uniquely enables live mutation of running systems means overlooking Erlang, the telecoms language created by Ericsson (Erlang – Wikipedia).

From the late 1980s onward, Erlang supported hot code swapping in safety-critical telephony infrastructure. Far from exploratory hacking, this was production engineering under strict uptime requirements.

Live systems were already operational long before Clojure appeared.

What Clojure actually contributes

Clojure's achievement lies elsewhere.

It brings together:

the Lisp REPL tradition
the JVM ecosystem
persistent data structures (Persistent data structure – Wikipedia)
modern concurrency primitives

This synthesis is real and valuable, and the result of thoughtful engineering.

Interactive programming and the REPL itself, however, sit firmly in the inherited category.

The real trade-off: semantic mutability

The distinctive characteristic of Clojure's REPL is not persistence per se, but the level at which persistence operates.

Early BASIC systems preserved data. Numbers, arrays and flags survived across runs. Control flow remained linear, and program meaning remained fixed.

Clojure extends persistence to meaning. Functions may be redefined live. Dispatch rules can be altered. Existing call sites can acquire new behaviour without any obvious signpost.

This shift increases expressive power, but the engineering bill arrives as reduced reconstructability and predictability.

Clojure: silent semantic drift

;; Session start: define calculate
user=> (defn calculate [x] (* x 2))
#'user/calculate

user=> (calculate 5)
10

;; Later, perhaps in another file or by another developer:
user=> (defn calculate [x] (+ x 100))   ; silently replaces original
#'user/calculate

user=> (calculate 5)
105
;; No warning. No error. Source file unchanged.

For a single developer, this is simply a useful tool. In a team, it becomes a coordination hazard: runtime truth can drift away from the text everyone believes they are running.

On Rich Hickey's position

In talks such as Simple Made Easy (InfoQ video) and various discussions of REPL-driven development, Rich Hickey has argued that interactive development should be central, while edit–compile–run should be viewed as inefficient.

The intuition behind this argument is understandable. Iteration speed matters.

The framing, however, tends to obscure two facts:

interactive development long predates Clojure
many systems combine interactivity with compilation discipline

Growing systems live accelerates exploration, but it also erodes the ability to reconstruct behaviour from source alone. That trade-off deserves to be stated explicitly.

Hickey did not claim the REPL was new. The Clojure community, however, often treats it as a unique truth.

A structural comparison

A clearer perspective emerges from comparing REPL models across history.

Legend: ✅ Yes, ❌ No, 🟡 Limited

Property	1958–60: Lisp REPL (image-based)	1964: Dartmouth BASIC	1977–85: Home BASIC	1973–: ML / OCaml REPL	2005–: F# REPL	2007–: Clojure REPL
Interactive evaluation	✅	✅	✅	✅	✅	✅
Immediate mode	✅	✅	✅	✅	✅	✅
Persistent session	✅	❌	✅	✅	✅	✅
Variables persist across runs	✅	❌	✅	✅	✅	✅
First-class functions	✅	❌	❌	✅	✅	✅
Live function redefinition	✅	❌	❌*	🟡	🟡	✅
Behavioural semantics mutable live	✅	❌	❌	❌	🟡	✅
Static type checking	❌	❌	❌	✅	✅	❌
Type system constrains REPL	❌	❌	❌	✅	✅	❌
Silent semantic mutation possible	✅	❌	❌	✅	✅	✅
Reconstructable from source alone	❌	✅	✅	✅	✅	❌
Designed for long-lived systems	✅	❌	❌	✅	✅	✅

BBC BASIC excepted; most home BASICs lacked named functions and relied on line-numbered subroutines.

A counterexample: the ML lineage (OCaml and F#)

F# is not an outlier. It belongs to a lineage – ML and OCaml (OCaml – Wikipedia) – that has treated interactive, typed REPL-driven development as normal practice for over forty years.

F#'s REPL chooses constraint over maximal dynamism, but the mechanism deserves to be described accurately.

F# allows shadowing with a new binding. When type signatures match, however, F# offers no protection against semantic drift – the same 'silent mutation' problem exists as in Clojure:

// F#: type system provides no protection when signatures match
> let calculate x = x * 2;;
val calculate: x: int -> int

> calculate 5;;
val it: int = 10

> let calculate x = x + 100;;   // same signature, different semantics
val calculate: x: int -> int

> calculate 5;;
val it: int = 105
// Same silent semantic drift as Clojure

The difference is that F#'s type system provides partial protection: it prevents one class of errors (type mismatches at call sites) but not semantic changes within the same type. When a function is redefined with a different type signature, the type system catches inconsistent usage at the point of application, forcing the programmer to address the incompatibility explicitly.

For teams that value refactoring, long-term maintenance and source-level truth, this partial discipline often proves advantageous – though it does not eliminate the reconstructability problem entirely.

"But Clojure's REPL is integrated"

A predictable rebuttal points to tooling: CIDER (https://cider.mx), nREPL (https://nrepl.org) and editor integration.

Better tools improve the experience. They do not alter the underlying model, which remains rooted in a design first implemented in the 1950s.

Why the mythology persists

The persistence of the REPL myth is easy to explain:

Lisp culture has always emphasised interactivity
computing history before the web is poorly remembered
expressive power is often confused with novelty
difficulty is frequently mistaken for depth

None of this indicates bad faith, but it does reward clearer framing.

This transition took place more than a generation ago. As a consequence, the interactive environments that once defined everyday programming gradually slipped from the memory of both enthusiasts and professionals. Later rediscoveries of REPL-driven workflows were then easily mistaken for innovations rather than revivals.

Conclusion

The REPL is an immensely valuable tool. Its lineage stretches back more than six decades. Clojure's indisputable power rests heavily on it, but that power arrives through inheritance rather than invention.

Other languages explore the same design space differently, sometimes with stronger engineering constraints.

It is also worth noting a structural echo. REPL-driven workflows treat programming as a dialogue rather than a batch process, and today's agent-driven coding tools adopt a similar stance. They extend the conversational model from interaction with a running program to interaction with an entire codebase. It would be a stretch to claim a direct causal link, but the resemblance is clear: both approaches reject the assumption that code must be "finished" before it can be tested against reality.

Clojure's REPL offers power and has made a great deal of noise. It has reinvigorated an old paradigm and delighted its community. Power is not, however, novelty; and enthusiasm must not rewrite history.

Acknowledgments

Thanks to Frank Adrian for pointing out that the original F# example compared type-system differences rather than REPL-model differences. The corrected example now shows how F#, like Clojure, permits silent semantic drift when function signatures remain unchanged; the F# type system provides only partial protection against this class of error.

References

Read–Eval–Print Loop (REPL) – Wikipedia
https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop
History of Lisp – Wikipedia
https://en.wikipedia.org/wiki/History_of_Lisp
L. Peter Deutsch & Edmund Berkeley, LISP on the PDP-1 (1964)
https://softwarepreservation.computerhistory.org/projects/LISP/book/III_LispBook_Apr66.pdf
Joseph Weizenbaum, OPL-1 on CTSS (1964)
https://dspace.mit.edu/handle/1721.1/149332
Compatible Time-Sharing System (CTSS) – Wikipedia
https://en.wikipedia.org/wiki/Compatible_Time-Sharing_System
David A. Moon, Maclisp Reference Manual (1974)
https://www.softwarepreservation.org/projects/LISP/MIT/Moon-MACLISP_Reference_Manual-Apr_08_1974.pdf
Scheme REPL terminology history
https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop
Edinburgh LCF – Wikipedia
https://en.wikipedia.org/wiki/Edinburgh_LCF
Smalltalk – Wikipedia
https://en.wikipedia.org/wiki/Smalltalk
BASIC – Wikipedia
https://en.wikipedia.org/wiki/BASIC
Visual Basic (classic) – Wikipedia
https://en.wikipedia.org/wiki/Visual_Basic_(classic)
VB.NET – Wikipedia
https://en.wikipedia.org/wiki/Visual_Basic_.NET
Erlang (programming language) – Wikipedia
https://en.wikipedia.org/wiki/Erlang_(programming_language)
Persistent data structure – Wikipedia
https://en.wikipedia.org/wiki/Persistent_data_structure
Rich Hickey, Simple Made Easy (InfoQ video)
https://www.infoq.com/presentations/Simple-Made-Easy/
OCaml – Wikipedia
https://en.wikipedia.org/wiki/OCaml
CIDER
https://cider.mx
nREPL
https://nrepl.org