Inko: a language where the compiler refuses to let you race

The pitch is confidence, and the features are the mechanism

Inko describes itself as a language for building concurrent software with confidence, and the argument is that it makes it easy to build concurrent software without having to worry about unpredictable performance, unexpected runtime errors, or race conditions.

The feature list is what backs that claim. Inko has deterministic automatic memory management, move semantics, static typing, type-safe concurrency, efficient error handling, and more. Source code is compiled to machine code using LLVM.

Read the list carefully, because each item answers a specific failure mode. Deterministic automatic memory management is the answer to a garbage collector that pauses at unpredictable moments and to reference counting that leaks cycles, which is a different kind of unpredictable performance. Move semantics is the answer to the classic ownership transfer problem, where a value has to be copied before it can be given away, and the copy is what makes concurrent access hard. Type-safe concurrency is the answer to race conditions, and it is the item that distinguishes Inko from a language with a runtime race detector.

The deterministic part deserves emphasis, because it is the unusual one. A garbage collected language can promise correctness about memory but not about timing, and a timing problem in a concurrent program is exactly the kind of bug that is hardest to reproduce. A language with deterministic memory management promises that a collection happens at a point you can point to in the source, which means a program that hangs does so for a reason you can find.

The primary language of the implementation is Rust, and the project topics list compiler, inko, llvm, programming language and rust, so the type system and the runtime are built in a memory safe host language while the compiler emits native code through LLVM.

The hello world shows the type system doing the work

The first example in the README is the smallest possible program, and even it carries the language's central idea.

import std.stdio (Stdout)

type async Main {
  fn async main {
    Stdout.new.print('Hello, world!')
  }
}

Two things stand out. The type is declared `async`, and the method is declared `fn async main`. The async keyword is not a keyword inside a function body, it is part of the type's definition, which means concurrency is a property of the type rather than of a function body. The object is a process, and it runs its own message loop, so `Main` has a `main` method that the runtime invokes.

The second example makes the mechanism concrete. A `Calculator` type is declared `async` too, and it takes a `uni Promise[Int]` as an output parameter, where `uni` is Inko's uniqueness qualifier, the type system expression of the idea that a value can be owned by exactly one process at a time.

type async Calculator {
  fn async fact(output: uni Promise[Int], size: Int) {
    let result = 1.to(size).iter.reduce(1, fn (product, val) { product * val })

    output.set(result)
  }
}

The call site then awaits the result.

let val = await calc.fact(15)

What the second example demonstrates is that the concurrency model is not bolted on with a thread library. The `async` on the type, the `uni` on the promise, and the `await` at the call site are the same mechanism seen from three angles. The comment in the example says it calculates the factorial of 15 in the background and waits for the result to be sent back, and the output prints the result to standard output.

For someone reading to learn, this is the right place to start, because the whole language is visible in about twenty lines.

A workspace of five crates, with the standard library alongside

The repository layout tells you the shape of the implementation, and it is unusually flat for a language.

The Cargo.toml declares a workspace with five members: ast, inko, compiler, rt and location, using resolver version 2. The workspace package version is 0.21.1 and the minimum Rust version is 1.89. The release profile sets panic to abort, and there is a separate release-debug profile that inherits release and turns on debug information, which is the kind of detail that tells you the maintainer actually profiles binaries.

The top-level directories map onto those crates. ast/ is the abstract syntax tree, compiler/ is the compiler itself, rt/ is the runtime, location/ handles source locations, and inko/ is the driver. Then there are directories that are not workspace members: std/ for the standard library, types/ for the type system, docs/ for the manual, ci/ for continuous integration, scripts/ for helper scripts, and a Dockerfile plus a Makefile at the root.

The Rust toolchain is pinned with rust-toolchain.toml, formatting is configured with rustfmt.toml, linting with clippy.toml, and dependency auditing with deny.toml. There is a .vale.ini for prose linting, which is a detail worth noting, because it means the documentation is checked for style in continuous integration like the code is checked for correctness. There is a CHANGELOG.md, a CONTRIBUTING.md, a .mailmap, and clogs.json, which is the configuration for a changelog generator.

The version number is the thing to note. 0.21.1 is a pre 1.0 version, and the project's own framing is that of a language under active development, which is a reasonable thing to study and a risky thing to depend on.

Building on LLVM, and why the Dockerfile needs libffi

The Dockerfile is short and contains one comment that explains a real dependency chain.

The build stage is based on a Fedora minimal image, and the comment says Fedora builds LLVM with libffi support, and that when statically linking against LLVM the build will fail if libffi-devel is not installed, with a link to an issue on llvm-sys.rs for extra details. The packages installed are gcc, make, rust, cargo, the LLVM packages including llvm-static, the C++ runtime development and static packages, libffi-devel, zlib-devel and libxml2-devel.

Then the build itself is two make targets, a release build and an install, with the binary stripped afterwards.

make build PREFIX='/usr'
make install PREFIX='/usr'

The runtime stage is the same Fedora minimal base with gcc, tar and git, and the comment there notes that gcc is needed to link object files, which also pulls in libgcc, and that the generated code links against that dynamically. The final image copies the inko binary, the standard library from /usr/lib/inko, and the licenses.

So the practical build requirements are: a Rust toolchain at 1.89 or newer, an LLVM installation with development headers, and a C++ toolchain for the LLVM linkage. The Makefile mirrors the layout, with a PREFIX defaulting to /usr, a LIB variable, and install targets for the inko executable, the standard library under /usr/lib/inko/std, the runtime library as a static libinko.a, and the license file.

The Makefile also contains the release machinery, with a version derived from cargo pkgid, a source tarball built with git archive, a manifest file, and separate targets for the documentation site and the releases site. That is the shape of a language project that intends to ship its own releases rather than rely on a package manager.

What the language does not give you yet

The honest limits of Inko come from three places, and none of them is a design flaw.

The first is the version. 0.21.1 with no GitHub releases means the language is pre 1.0, so the language itself and the standard library can still change in ways that break your code. The last push was on 2026-10-13 and the repository is not archived, so it is moving, and movement before 1.0 is normal, but it is movement you inherit.

The second is the standard library. The std/ directory exists and the examples import std.stdio and std.sync, which tells you the library is organised by module with the module path as the import path. But a young language's standard library is a fraction of what a mature one offers, and anything missing is code you write and then maintain. For a language whose selling point is concurrency, the relevant gap is anything to do with asynchronous I/O beyond what std.sync provides.

The third is the ecosystem. There is no package registry equivalent described, no list of third party libraries, and no mention of a framework layer. A language with a small standard library and no ecosystem means every dependency is either vendored by you or written by you.

None of this makes Inko a bad project. It makes it a specific kind of project: a language implementation you can read, with a compiler and a runtime in one repository and a type system built around a clear idea about ownership and isolation. For evaluation, study it. For production, the version number is the deciding fact, not the design.

MPL-2.0, and what it means for a language implementation

All source code in the repository is licensed under the Mozilla Public License version 2.0, unless stated otherwise, with a copy of the licence in the LICENSE file.

MPL-2.0 is a file-level copyleft licence, and for a language implementation it has a specific meaning worth understanding rather than assuming. If you take a file from the Inko source and modify it, your modified version of that file must be published under the same licence. But if you use the Inko compiler or runtime as a separate program that communicates with your code, as a compiler and a runtime naturally do, that is not a derivative work of those files.

That is the practical case for most adopters. Running the inko compiler to build your own program, or linking against the runtime, is the intended use, and MPL-2.0 is designed to permit exactly that. The obligation bites if you patch the compiler itself and distribute the patched version.

There is one more detail in the build machinery worth noting for anyone thinking about redistribution. The Dockerfile copies the licence files from /usr/share/licenses/inko into the final image, and the Makefile has a dedicated install target for the LICENSE file at /usr/share/licenses/inko/LICENSE. Distributing an Inko toolchain therefore involves carrying the licence with it, and the project has thought about where that file should land.

The documentation and the website are published separately from the repository, with the manual at docs.inko-lang.org and the project site at inko-lang.org, and there is a Discord server for following development.

Editorial conclusion

Inko fits a systems programmer who wants to understand what type-safe concurrency looks like when it is enforced by the compiler rather than by a runtime, and who wants to read a language implementation that is small enough to hold in their head, since the compiler, the runtime and the standard library are all in one repository. It does not fit a team shipping a service this quarter, because the version is 0.21.1, the standard library is a subset of what a general purpose language offers, and the ecosystem around it is thin. Check three things before you commit. Check the standard library, because the whole point of the language is concurrency and the amount of std available determines how much you write yourself. Check the type system against your problem, because the safety guarantees come from ownership and isolation, and a program that fights those rules will not compile. And check the build, because compiling to machine code through LLVM means a Rust toolchain, an LLVM installation and a release profile with panic set to abort. The last push was on 2026-10-13, the repository has no GitHub releases, and the licence is MPL-2.0.

Frequently asked questions

Official sources

1. inko-lang/inko on GitHub
2. Issues
3. License: MPL-2.0
4. Project website
5. README