The Return of Algol 68
Sun, 8 Feb 2026
I was catching up on my backlog of FOSDEM 2026 talks - you know how it goes, the schedule is always packed - when I clicked through to Jose Marchesi's update on the GNU Algol 68 project.
I've been following the development for a while. I knew the frontend had finally landed in the GCC trunk and was slated for the GCC 16 release this coming Spring. I was expecting a solid status report: some details on the test suite, some new compiler flags, a demo of the new automake integration.
What I wasn't expecting was a direct challenge to the current king of systems programming safety.
Jose didn't just demo a retro-computing curiosity; he made a very specific, technical argument: that Algol 68 - a language defined in 1968 - is, in practice, safer than Rust. Not just "as safe," but safer.
It sounds like heresy in 2026. But after digging into the Revised Report and examining its runtime safety checks, he has a point, making Algol 68 a compelling safety alternative.
For the uninitiated, ga68 isn't an emulator or an interpreter designed to run dusty punch-card decks. It's a full-fledged GCC frontend. This means Algol 68 is joining C, C++, Fortran, Ada, and Go as a first-class citizen within the GNU Compiler Collection.
The project's been moving fast. The frontend was merged into GCC in November 2025. This locks it in for the upcoming GCC 16 release.
This isn't a nostalgia trip. Jose and the new GNU Algol 68 working group are reviving the language as a serious and practical tool for modern development. They aren't treating it as a "dead" language to be studied, but as a "sleeping" language to be woken up. The implementation includes full support for the standard GNU toolchain - meaning you can use automake, autoconf, and GDB just as you would with C. It compiles to machine code, links with standard system libraries, and interacts with the OS without needing a special runtime sandbox.
In short: Algol 68's back, and it's shipping in the same compiler suite that powers the entire free software ecosystem.
The boldest assertion emerging from the FOSDEM talk is that while Rust has succeeded in reviving interest in tooling, it fails as a language due to its complexity. The argument is stark: Rust is "awful" to write, whereas Algol 68 - once fully equipped with its specified runtime checks - offers superior safety without the struggle.
This claim hinges on a fundamental difference in how "safety" is defined and enforced.
Rust achieves safety through static analysis. Its borrow checker rigorously enforces ownership and lifetimes at compile time. If the compiler cannot prove your code's safety, it refuses to build it. This is the famous "zero-cost abstraction," but it comes with a high cognitive cost: the developer must constantly prove their memory logic to the compiler.
Algol 68, by contrast, relies on dynamic safety. The language specification mandates strict Scope Rules that prevent dangling pointers (references to data that no longer exist). Instead of forcing the programmer to manage lifetimes with complex syntax explicitly, the runtime environment enforces these rules as the program executes.
The trade-offs are clear: Rust demands you solve the safety puzzle before you can even run your code. Algol 68 lets you write natural, algorithmic code, trusting the runtime to catch any violations. Safety is implicit in the environment rather than explicit in the source code.
The rule is elegantly simple and crucial for safety: You can't assign a reference to a variable if the reference's scope is shorter than the variable's. If you declare a variable inside a block (a local scope), its lifetime is bound to that block. If you try to assign a reference to that local variable to a pointer that lives outside that block (a global or heap scope), the assignment is invalid.
In Rust, the compiler yells at you before you can even run the program, enforcing safety at compile time. In C, the compiler stays silent, risking crashes or memory corruption later. In Algol 68, the runtime check catches scope violations immediately, ensuring safe execution without the overhead of static analysis.
This is what I call "Zero-Cognitive-Cost" Safety. You don't have to wrestle with lifetime annotations or fight the borrow checker. You write your algorithm naturally. If you make a mistake with scopes, the runtime protects you. You get the memory safety of a managed language without the overhead of a heavy garbage collector or the complexity of a static prover. It's safety that gets out of your way until you actually need it.
This leads to the most critical distinction in the safety debate: the escape hatch.
In Rust, the borrow checker is notoriously strict. It's so strict, in fact, that implementing common data structures - like a doubly linked list or a graph with cycles - is often impossible using safe Rust alone. To get around this, the language provides the unsafe keyword. This is an escape hatch that allows the programmer to tell the compiler, "Trust me, I know what I'm doing." Inside that block, the safety guarantees vanish, and you're back to manual memory management with all its potential for segmentation faults and data races.
This creates a paradox: to write advanced, high-performance systems code in the "safest" language, you often have to turn off the safety mechanism.
Algol 68 takes a different approach, rooted in Orthogonality. The language was designed so that its features - references, structures, and unions - combine uniformly without edge cases that require rule-breaking.
Take Unions, for example. In C (and unsafe Rust), a union is just a raw chunk of memory that you can interpret however you want - a classic source of bugs. In Algol 68, a UNION is a Tagged Union (what Rust calls an enum, but Algol had it in 1968). The runtime carries the type information with the data. To access the value inside a union, you must use a Conformity Clause (a case statement). If you try to access an integer as a pointer, the program doesn't segfault or corrupt memory; the runtime check directs you to the correct handler or halts.
There's no unsafe keyword in Algol 68. There's no mode to turn off scope checks or the type system. The language is safe everywhere, not just mostly. You can build complex, self-referential data structures using standard language features, secure in the knowledge that the runtime is still watching your back.
It's easy to dismiss a language from the 1960s as archaic, assuming it lacks the sophisticated abstractions we enjoy today. But when you look at Algol 68, you realize that what we consider "modern" programming is often just the rest of the world catching up to Adrian van Wijngaarden's design.
Expression-Oriented Programming: One of the features Rust developers love most is that "everything is an expression." You can assign the result of an if block or a loop directly to a variable. Algol 68 was doing this half a century ago. Unlike C, where statements (like if or while) are distinct from expressions and return no value, Algol 68 treats almost every construct as a unit that yields a value. This allows for concise, functional-style logic without the need for auxiliary variables or side effects - a hallmark of modern clean code.
First-Class Procedures: In many older languages, functions are static blocks of code you jump to. In Algol 68, a procedure is a value with a specific mode (type). You can pass procedures as arguments to other procedures, return them, or store them in data structures. This enables higher-order functions and a programming style that feels remarkably like using lambdas in Python or JavaScript, while maintaining strict static type checking.
Concurrency as a Primitive: Perhaps the most shocking feature to find in a 1968 specification is the Parallel Clause. Long before pthreads or Java made threading mainstream, Algol 68 introduced the PAR keyword. By simply prefixing a block with PAR, the compiler generates the necessary fork-join infrastructure to run the enclosed statements concurrently. But it didn't stop at launching threads; the standard library (the "standard prelude") included semaphores and mutexes as built-in types. The language designers recognized that concurrency was the future of computing and baked the synchronization primitives directly into the core definition.
One of the most compelling arguments isn't about syntax, but about citizenship.
Modern languages often arrive with a philosophy of isolation. Go has its own unique way of handling dependencies; Rust lives inside cargo; Node has npm. They create "language ghettos" - walled gardens where the tooling is excellent as long as you stay inside the walls, but integrating with the rest of the system becomes a headache of FFI bindings and complex build scripts.
The GNU Algol 68 project takes the opposite approach. It aims to be a "good citizen" of the free software ecosystem.
Modernizing the Syntax: Sapper Stropping: To make the language usable on modern terminals, the GNU implementation introduces "Sapper stropping." In the 1960s, "stropping" was the method used to distinguish keywords (like BEGIN or REAL) from user variables. You either had to type everything in uppercase or wrap keywords in quotes ('BEGIN'). Sapper stropping is a pragmatic GNU extension that allows for a mix of upper-case keywords and standard identifiers, making Algol 68 code look and feel like a modern language while retaining its rigorous parsing structure.
The Toolchain is the Ecosystem: Crucially, ga68 is designed to work with the standard GNU toolchain, not replace it.
- Build Systems: You don't need a special Algol build tool. You use Automake and Autoconf. The project has already upstreamed support, meaning you can mix Algol 68 sources right alongside C and C++ in your Makefile.am.
- The Linker: It uses the system linker (ld). It produces standard shared objects (.so). This means you can write a library in Algol 68 and link it dynamically against a C program, or vice versa, without massive overhead.
By adhering to these standards, GNU Algol 68 allows developers to incrementally adopt the language for safe system components without rewriting their entire infrastructure. It respects the operating system rather than trying to abstract it away.
Why This Matters
The return of Algol 68 proves a vital point: "old" doesn't mean "obsolete."
We sometimes fall into the trap of thinking that the problems we face today - memory safety, concurrency, build complexity - are unique to the modern era, and that our solutions must therefore be novel. But Jose Marchesi and the GNU Algol 68 project have shown us that the solutions were already there, buried in a report, waiting for the hardware to catch up.
The claim that Algol 68 is "safer than Rust" isn't meant to diminish the incredible work done by the Rust community. It offers an alternative path to safety - one that relies on rigorous, orthogonal language design and robust runtime support rather than placing the entire cognitive burden on the developer at compile time.
I encourage you to visit algol68-lang.org. Download the Revised Report (or the much friendlier Informal Introduction).
We spend so much time looking forward to the next big framework or language feature. It may be time we looked back. The key to a safer, more sane future for systems programming might just be waiting for us in the past.