Silq type checks quantum programs before they reach a simulator

A language built around the reversibility constraint

Silq is a high-level programming language for quantum computing with a strong static type system, and the project describes itself as a type checker, compiler and experimental interpreter. The interesting design decision is visible in the repository's topic tags, one of which is reversible programming language. A quantum program is not an ordinary program, because the operation of computing is not reversible in the way a classical function is, and a language that ignores that produces programs that cannot be compiled to a circuit. A static type system is the mechanism Silq uses to enforce the discipline, so an error that a classical compiler would accept is rejected at type check time. The effect for a user is that the feedback loop is fast and the failure is precise. You do not discover that your function cannot be implemented as a gate sequence after you have written 200 lines of it, and you do not find out through a simulator that misbehaves. The project is from ETH Zurich, and the more detailed documentation lives at silq.ethz.ch, with the repository README serving as the quick orientation.

Two commands, one for checking and one for simulating

The command line surface is small, which is a good sign for a language whose complexity lives in the type system rather than in the tooling. To type check a source file you invoke the binary with the file name, running ./silq example.slq, and adding the --run flag type checks the file and simulates the main function in it. A third option, running the binary with --help, displays information about the supported command-line options. The separation between the two modes is worth noticing, because it reflects how the project describes its own components. The type checker and the compiler are the primary artefacts, and the interpreter is called experimental. So the realistic workflow is that you write a Silq program, you check that it type checks, and then you use --run to watch the main function execute in simulation. The simulator is described as qsim in the source tree, alongside silq.d for the compiler driver, lsp.d for what looks like language server support, astopt.d for AST optimisation and hqir.d for the intermediate representation. The presence of an hqir file alongside the type checker suggests the type checker runs on an intermediate form rather than on the surface syntax, which is a reasonable way to build a static checker for a domain-specific type system.

Building it means installing a D compiler first

The build path is scripted, and the scripts are the whole installation procedure on GNU/Linux and macOS. The quick build has two steps, first running dependencies-release.sh to download the LDC D compiler into the local directory, and then running build-release.sh to build Silq. The two can be chained in a single line.

$ ./dependencies-release.sh && ./build-release.sh

Silq is written in the D programming language, and the documentation notes that D compilers are available from the dlang download page, so the dependency script is a convenience rather than a requirement. That detail matters because the repository pins a specific compiler in a file named version-ldc.txt, and because the tree contains separate scripts for the different platforms, with build-release.sh, build-ldc.sh, build-xosx-release.sh, build-xwindows-release.sh, build-all-platform-release.sh and a plain build.sh, plus matching dependencies scripts for release, macOS, Windows and the generic case. So the project does support Windows and macOS builds, it just does not document them as the primary path. If you are on GNU/Linux or macOS, the quick build is the route, and if you are elsewhere the invitation is to contribute working build scripts for your platform.

FreeBSD is the one platform with a package story

FreeBSD gets more attention in the build instructions than you would expect, and the reason is a specific dependency rather than a preference. Silq can be built from a port or installed as a binary package on FreeBSD/amd64, while other FreeBSD platforms do currently lack the D language support required by Silq. Assuming an up-to-date ports tree is available, the source install is a two step affair in the language's port directory.

$ cd /usr/ports/lang/silq
$ make install

The documentation also mentions portmaster and the other ports management tools as alternatives. Installing from a package is a single command.

$ pkg install silq

This is a useful signal about the project's maturity. A language that has a ports tree entry and a binary package is a language that other people have already packaged for a second platform, and the same section makes the corresponding point for a third. Meanwhile the editor install path is separate again, with a pointer to the install guide for installing via VS Code without building from source, and the repository's own site at silq-lang.org. The licence is the Boost Software License 1.0, a permissive source-available licence, which is worth noting because the repository records no GitHub releases and the versions are tracked in the source tree rather than in tags.

Where the type system is the limitation

The obvious tension in this project is that the same mechanism that makes Silq valuable is what makes it restrictive. A strong static type system that rejects non-reversible code will also reject code that is perfectly reasonable to write and awkward to express in a reversible style, and any operation that the type checker does not model becomes something you either work around or cannot do. The repository layout hints at the scope of that modelling work, with a library/ directory, a test/ directory, an ast/ directory and the .gitmodules file for submodules. For a language in this category, the set of supported operations is the real specification, and the documentation available here does not enumerate it, so the practical question for an adopter is whether the gates your algorithm needs are in the type system or around it. The second limitation is the interpreter. The project calls it experimental, and the simulation path is a separate component, so the maturity of the simulation is not the maturity of the type checker, and it is worth knowing which half you are relying on for a given task. The third is that the project has no published releases, so there is no version to pin and no changelog to read. The last push was on 2026-10-20, so the code is being worked on, but the distribution is via build scripts and the platform guide rather than tagged artifacts.

Editorial conclusion

Adopt Silq if you want a quantum language where the compiler rejects non-reversible programs before you ever reach a simulator, and you are willing to write inside the reversibility discipline the type system enforces. Skip it if you need a general purpose language with quantum libraries, since Silq is its own language rather than a library for Python or Julia, and skip it if you need a maintained release cadence with published binaries, because the repository has no GitHub releases. Before you start, read the install guide, since the editor path avoids building from source, and check that the type checker covers the operations your algorithm actually needs.

Frequently asked questions

Official sources

1. Issues
2. License: BSL-1.0
3. Project website
4. README
5. silq-lang/silq on GitHub