Jakt: A Memory-Safe Systems Language That Transpiles to C++

What Jakt Is and Why It Transpiles to C++

Jakt is a systems programming language developed under the SerenityOS organization. The goal is to write code that is safe by default without sacrificing the low-level control that systems programming requires. Rather than targeting machine code directly, Jakt currently compiles Jakt source files into C++ source files, which are then compiled by clang.

This approach lets Jakt use the mature C++ toolchain for code generation, optimization, and platform support while adding safety guarantees at the language level. The trade-off is that every Jakt project depends on both the Jakt compiler and a compatible C++ compiler. The basic compile and run cycle for a Jakt file is:

jakt file.jakt
./build/file

The transpilation step requires clang. The README notes this as a prerequisite.

How Jakt Enforces Memory Safety

The README lists four mechanisms for memory safety: automatic reference counting, strong typing, bounds checking, and no raw pointers in safe mode.

Jakt defines three pointer types. A strong pointer (`T`) holds a reference-counted class instance. A weak pointer (`weak T`) also points to a reference-counted instance but becomes empty if the pointee is destroyed, avoiding dangling pointer access. A raw pointer (`raw T`) is an unrestricted pointer to any type but is only usable inside `unsafe` blocks.

Null pointers are not possible in safe mode. When a value might be absent, the language uses `Optional<T>`, also written as `T?`. The language supports optional chaining with `?.` for fallible access and `!.` for infallible access. The none-coalescing operator `??` yields the optional's value if present, otherwise a fallback.

For numeric safety, integer overflow on both signed and unsigned types is a runtime error. Numeric values are not automatically coerced to `int`; all casts must be explicit. For the cases where silent overflow is intentional, the language provides explicit functions with that behavior.

Building the Compiler with CMake and Docker

The build system uses CMake with Ninja. The repository includes a Dockerfile that installs all dependencies and builds the compiler from source on Ubuntu 24.04:

# To build: docker build --no-cache -t jakt:latest -f Dockerfile .
# To run: docker run -it jakt:latest

The Dockerfile installs build-essential, cmake, git, ninja-build, clang, and libclang-dev, then configures the build:

cmake -B build -GNinja -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang -DCMAKE_INSTALL_PREFIX=jakt-install
ninja -C build install

The build documentation references `documentation/cmake-bootstrap.md` for more detail. The repository root contains a `bootstrap/` directory, indicating the compiler has a bootstrap phase. The top-level directory also contains `selfhost/`, which holds the Jakt-in-Jakt implementation of the compiler.

Windows users cloning the repository outside WSL need to set `git config --global core.autocrlf false` before cloning, because the repository expects Unix line endings. This is noted explicitly in the README.

Language Design: Immutability, Named Arguments, and Struct vs Class

Variables in Jakt are immutable by default. Mutation requires the `mut` keyword. This applies to both local variables and function parameters, including the implicit `this` parameter in class methods.

Function calls require argument labels:

rect.set_size(width: 640, height: 480)

Two exceptions apply: a parameter declared with `anon` in the function declaration can be passed without a label, and a variable whose name matches the parameter name does not need a label.

Jakt distinguishes between `struct` and `class` with different semantics. Structs have value semantics: copying a struct creates a deep copy, and all members are public by default. Classes have reference semantics: copying a class copies a reference, all instances are reference-counted automatically, and members are private by default. The `.foo` shorthand in a method body expands to `this.foo`.

The README lists several class features that are not yet implemented: class-based polymorphism for assigning child instances to parent-typed variables, the `Super` type, and the `Self` type.

The Module System and the Standard Library

Jakt has a built-in module system with six import forms:

import a
import a { use_cool_things }
import fn()
import relative foo::bar
import relative parent::foo::baz
import relative parent(3)::foo::baz

The first two forms import a module from the same directory or a specific symbol from it. The third form evaluates the import at compile time, a feature called comptime imports. The `relative` forms handle sub-paths and parent paths without requiring absolute module names, with `parent(3)` as shorthand for three levels up.

The standard library lives under the `jakt::` namespace:

import jakt::arguments
import jakt::libc::io { system }

The README describes the standard library as in its infancy and explicitly invites contributions. Engineers who need a comprehensive standard library will find significant gaps.

Real Limitations of the Current State

The README opens with two explicit notes: the language is under heavy development, and Windows users must configure Git for Unix line endings. Heavy development means the language specification, syntax, and standard library are not stable. A project built on Jakt today must be prepared for breaking changes.

The transpile-to-C++ architecture adds a dependency on clang that will remain for any project until Jakt supports direct machine code emission. The compiler's output is C++ source, which a C++ compiler then builds. Debugging output involves understanding both Jakt source and the generated C++ code.

Several class features are listed as not yet implemented, including class-based polymorphism. The standard library is described as being in its infancy. The repository has no tagged releases, so there is no versioned stable snapshot to pin to.

Pattern matching with `match` is implemented, but error propagation with `ErrorOr<T>` and the `try`/`must` keywords is listed as not yet complete in the README's feature checklist.

How Jakt Differs from Zig

Zig is a systems programming language that compiles directly to native code without a C++ intermediary. It targets C interoperability directly and ships a self-contained compiler binary. Zig has versioned releases, a documented standard library, and a stable release channel.

Jakt's approach differs in two ways. First, it transpiles to C++ rather than native code, meaning it relies on clang for the final compilation step. Second, Jakt places more emphasis on readability features: named argument labels, optional chaining, and the struct/class distinction with different default visibility and copy semantics are design choices Zig does not make.

Jakt is developed alongside SerenityOS as a practical language for that project's needs. Zig positions itself as a general-purpose systems language with wide adoption goals. Engineers choosing between them today will find Jakt lacks the stability and library coverage that Zig's versioned releases provide.

Maintenance, License, and Sample Coverage

The last push to the repository was on 2026-08-21. The repository is not archived. There are no GitHub releases; version tracking happens through commits to the main branch.

The license is BSD-2-Clause, located in the root LICENSE file. This is a permissive license with no copyleft conditions.

The repository includes a `samples/` directory with subdirectories covering arrays, booleans, classes, closures, compile-time execution, control flow, dictionaries, enums, functions, generics, guard, imports, inline C++, match, math, modules, namespaces, optionals, pointers, ranges, references, and sets. These samples serve as the primary working documentation alongside the README.

Editorial conclusion

Jakt is best suited to engineers who are already embedded in the SerenityOS ecosystem or who want to study a memory-safe systems language as it is being designed. The README marks the language as under heavy development, meaning APIs, syntax, and safety guarantees can change at any point. The transpile-to-C++ strategy means any project depending on Jakt must also manage a C++ toolchain. Engineers who need a stable, production-ready alternative to C++ should look at languages with versioned releases and documented stability policies. Verify whether the standard library covers the modules your project needs before committing, since the README itself notes the standard library is in its infancy.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-2-Clause
3. README
4. SerenityOS/jakt on GitHub