Ante: a functional systems language with safe shared mutability, built on a Rust-style ownership core

The problem Ante is aimed at: mutable references you can pass twice

Most languages force a choice. Either mutation is unrestricted and aliasing becomes a source of bugs, or borrowing is restricted enough that you cannot hold two mutable references to the same value. Ante's README describes its core as ownership and borrowing rules similar to Rust's, with the stated goal of being as readable as possible by encouraging high-level approaches that can be optimized with low-level details later. The feature it puts forward as the differentiator is safe, aliasable, borrowed mutable references. The README's taste snippet takes a parameter typed `mut Bar` alongside a borrowed `ref a`, calls a function with the same mutable argument twice, and annotates the return with a `Clone a` implicit constraint and a `Fail` effect. That single signature packs three of the language's research directions: shared mutability, traits through implicits rather than forced newtype wrappers, and effect handlers as part of the type. The intended audience is narrow and specific. This is a language for people interested in type systems and compiler construction, not a general purpose tool for shipping services. The README says the compiler is still in a rather early state and invites contributors to known issues or standard library additions, which tells you the project treats itself as a workbench.

How the compiler is put together: Rust front end, pluggable back end

The compiler is a Rust crate named `ante`, and the repository is laid out as a Cargo workspace with a second member, `ante-ls`, which is the language server. Backend selection is a Cargo feature, not a runtime flag. The default feature set is `llvm`, which pulls in the optional `inkwell` dependency configured for `llvm21-1`; disabling default features leaves the C backend as the fallback. That is a real architectural decision rather than a packaging detail: it means the LLVM path is the one most contributors are building against, and the C path exists mainly so the compiler can be built where LLVM is not available. The `examples/` directory is organized by compiler stage (`parser`, `nameresolution`, `typechecking`, `mir`, `codegen`) plus a `regressions` directory, which reflects a pipeline that lowers through a mid-level IR before code generation. Testing is integrated into the source tree rather than kept separate. The README explains that files in `examples` contain commands that the `goldentests` library uses to run the compiler and compare its output against expected output written in comments inside the same file. The `Cargo.toml` pins `goldentests` as a dev-dependency with default features off, and carries a comment that enabling its `parallel` feature makes `cargo t` nondeterministic. For a compiler project, that is a sensible design: the expected output lives next to the input, so a diff on a type error message shows up in the same review as the change that caused it.

Installing Ante: submodules first, then a backend decision

The README is explicit that cloning without submodules breaks compilation later, so start there. The failure mode is specific and worth knowing before you hit it: the README says you will get an error from clang complaining it cannot find `aminicoro.c`.

git clone --recurse-submodules https://github.com/jfecher/ante
# or
git clone https://github.com/jfecher/ante
cd ante
git submodule update --init

If you do not want to deal with LLVM at all, the README gives a one-line path that installs the compiler with the C backend instead. Note that this is the only documented way to opt out of LLVM; there is no runtime flag for it.

cargo install --path . --no-default-features

With LLVM 21.1 installed and its sources available, the README states that `cargo install --path .` should work directly. If the build still cannot locate the right version, the README points at an environment variable rather than a config file.

LLVM_SYS_211_PREFIX=$(llvm-config --obj-root)

On Linux and macOS the recommended route is your package manager, including any `-dev` packages. On Windows the README is blunt: LLVM binaries do not ship the appropriate library files, so the LLVM backend means building LLVM 21.1 from source with CMake, which in turn needs Visual Studio 2017 or later. If you are not specifically testing the LLVM backend on Windows, the README recommends the no-LLVM build. Nix users have a shorter path: Ante is in the unstable branch of nixpkgs, and the repository ships a `flake.nix`, so `nix-shell` or `nix develop` enters a development environment and `nix build` produces a build. The README also mentions `nix shell github:jfecher/ante` for trying the compiler without cloning. For a first real use, the README's own example is the honest starting point: a function taking `mut Bar` and `ref a`, calling another function with the same mutable argument twice, and returning something constrained by `Clone a` under a `Fail` effect. Compile that, then run the test suite with `cargo test --test goldentests` to see the expected-output machinery in action.

Where Ante will waste your time

The largest constraint is not in the language design, it is in the build. LLVM 21.1 is a hard requirement for the default backend, and the README states that older LLVM versions are not supported. That single sentence rules out most distributions' stock LLVM packages and pushes you either to a source build of LLVM through CMake or to the C backend. On Windows the cost is higher still, because the README says the LLVM binaries lack the needed library files. The submodule requirement is a second, smaller trap: a plain `git clone` followed by `cargo build` fails inside clang with a missing `aminicoro.c`, which is a confusing error for a problem that has nothing to do with your C toolchain. The C backend is the documented escape hatch, but the README presents it as a fallback for people without LLVM, not as a peer of the LLVM path, so expecting identical code generation from both is not something the documentation supports. Finally, the project's own framing limits what you should expect. The README calls the compiler early and asks for standard library contributions, which is a description of a language whose library surface is still being filled in. If you need a systems language for production work today, Ante is the wrong tool, and the last push on 2017-07-23 makes that a statement about the repository rather than about the ideas in it.

Ante compared with Rust, and with what it is not

The README positions Ante relative to Rust directly: it is built on a core of ownership and borrowing rules similar to Rust's, but aims for readability by encouraging high-level approaches that can be optimized with low-level details later. The concrete divergence is in the borrowing model. Rust's borrow checker does not let you hold two mutable references to the same value at once; Ante's README advertises safe, aliasable, borrowed mutable references, which is precisely the case Rust rejects. The second divergence is traits. Ante uses implicits for traits, and the README frames this as removing forced newtype wrappers, so a `Clone a` constraint appears in the signature rather than being satisfied through a wrapper type. The third is effects: the `Fail` effect in the example is written into the function's type, letting the body call `fail`, which is a different mechanism from returning a `Result` and propagating it by hand. The honest comparison is not feature parity, because there is none. Rust has a mature toolchain, a large ecosystem and a stable release history; Ante has a single repository, a website at antelang.org with a language tour and a roadmap, and a compiler the README describes as early. If you want to study an alternative borrowing discipline or effect handlers in a working compiler, Ante is the more interesting read. If you want to write software that ships, the comparison ends at the first build.

Maintenance, licence and the cost of an upgrade

The repository is not archived, but the last push was on 2017-07-23, and the most recent release listed is v0.8.0 on the same date, with v0.7.0 before it on 2017-04-25. The README describes the compiler as still in a rather early state and asks for contributors, and the community section points to a Discord as the best place to follow development, with a subreddit described as mostly inactive and mainly used for questions rather than development updates. Read together, those facts describe a project whose documentation is written for people who intend to work on it. The upgrade cost follows from the LLVM pin. The `Cargo.toml` requires `inkwell` 0.9.0 with the `llvm21-1` feature, and the README says older LLVM versions are not supported, so moving to a newer LLVM is not a matter of bumping a version string in your package manager; it is a change to the compiler's dependency configuration. The crate's own version field reads 0.1.0 while the releases are tagged v0.8.0, so do not treat the manifest version as the release you are running. The licence is MIT, which is permissive and, unlike a copyleft licence, does not require you to publish modifications you distribute. That is a statement about the licence text, not legal advice; if you plan to redistribute a modified compiler, read the LICENSE file in the repository rather than this paragraph. One practical implication of MIT combined with an inactive repository: if you fork Ante and change it, you carry the maintenance yourself, and there is no upstream release process to fold your changes back into.

Editorial conclusion

Ante is for people who want to read or modify a compiler that experiments with safe, aliasable mutable references and effect handlers, and who are comfortable installing LLVM 21.1 or accepting the C backend. It is not for anyone who needs a language with a stable release cadence, because the last push was on 2017-07-23 and the README itself calls the compiler early. Before adopting it, verify two things in the repository: that `git submodule update --init` has populated `aminicoro`, and which backend your build actually selected, since `cargo install --path .` defaults to LLVM and only `--no-default-features` switches to C.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes