Virgil compiles to native binaries, jars and WebAssembly from one source

A language whose compiler is written in itself

Virgil is described as a programming language designed for building lightweight high-performance systems, whose design blends functional and object-oriented programming paradigms for expressiveness and performance. The distinguishing property is in the implementation section: Virgil is fully self-hosted, with its entire compiler and runtime system implemented in Virgil. The repository therefore contains the compiler, the runtime system, some libraries, tests, documentation and supporting code for the various compilation targets, and the build starts with a bootstrap step that compiles the compiler with an already built version. A language that can build itself is a good way to test whether its type system and runtime can support a real program, and it means the codebase is a worked example rather than a specification.

Five features and one paper define the language

The language design section lists what Virgil balances in a statically typed language. Classes provide basic object-oriented programming. Functions cover small-scale reuse of functionality. Tuples give efficient aggregation and uniform treatment of multi-argument functions, which is the part that is unusual compared with a conventional OO language, since tuples in most languages are a library type rather than a first-class one. Type parameters provide abstraction over types. And algebraic data types make building and matching data structures easy. For more on the design there is a paper, plus a tutorial and a libraries document. The algebraic data types are what the later research work unboxes, and they are the feature that makes Virgil more than a small OO language with tuples bolted on.

Four target families from one compiler

The compiler produces optimized standalone native executables, WebAssembly modules, or JARs for the JVM, and for quick turnaround in testing and debugging programs can also be run directly on a built-in interpreter. The supported targets are listed precisely: x86-darwin and x86-64-darwin for 32-bit and 64-bit macOS kernels, x86-linux and x86-64-linux for 32-bit and 64-bit Linux kernels, jar for the Java Virtual Machine, and wasm for any WebAssembly engine. The compiler is naturally a cross-compiler, able to compile from any supported platform to any other, so you need only be able to run on one of the platforms in order to target any of the others. Linux binaries can also run on Windows through the Windows Linux system call layer, which is a neat consequence of the Linux target being a normal ELF binary.

Small binaries come from whole-program optimisation

The implementation section makes a specific claim about size and memory. Native binaries compiled from your programs can be as small as a few hundred bytes in size and consume just kilobytes of memory at runtime, and the README attributes much of that to the compiler including sophisticated whole-program optimizations that achieve great performance and small binaries. The design brief explains the audience: the language is well-suited to writing small and fast programs with little or no dependencies, which makes it ideal for the lowest level of software systems. On native targets it includes features that allow building systems that talk directly to kernels, dynamically generate machine code, and implement garbage collection, which is what makes it a research vehicle rather than just a small language.

The bootstrap is a shell script talking to aeneas

The Makefile shows the build structure and it is worth reading because the bootstrap is unusual. The default target depends on `bootstrap`, `utils` and `TAGS`, and the bootstrap target runs `bin/dev/aeneas bootstrap`, so the compiler that builds the compiler is a binary called aeneas that lives under the `aeneas/` directory. The stable target does the same with an option that redefines a debug field, `V3C_OPTS=-redef-field=Debug.UNSTABLE=false`, which is how the project separates a stable compiler from a development one. The utility programs are built the same way, each from its own directory under `apps/` with a call to `v3c-host` and a dependency list read from a `DEPS` file, producing tools named vctags, progress, nu, np and demangle. The naming is consistent: the source files use the `.v3` extension.

The bootstrap step itself is one target in the Makefile:

bootstrap: bin/stable/*/* $(AENEAS_SOURCE) $(LIB_UTIL) $(LIB_RT) $(LIB_ASM)
	bin/dev/aeneas bootstrap

The `stable` variant differs only in the option it passes, which is how the project keeps the released compiler and the development compiler apart.

The real user is a WebAssembly virtual machine project

The README says Virgil is currently being used for virtual machine and programming language research, in particular the development of a next-generation WebAssembly virtual machine called Wizard, and the topics attached to the repository list compiler, garbage collection, native, programming language, system programming, systems and webassembly. That tells you what kind of project this is. A language designed for people building runtimes needs low level control, needs to be small, needs to compile to WebAssembly so it can be a component of another system, and needs a garbage collector it can implement itself. The research papers back that reading, with six published papers on Virgil, the earliest from OOPSLA in 2006 on objects on the head of a pin, and the most recent on unboxing the algebraic data types, plus the PLDI 2013 paper on harmonising classes, functions, tuples and type parameters.

Where the documentation and the tooling live

The README makes the point that the most up-to-date documentation is the repository itself, with a getting started guide under `start/`, a tutorial under `doc/tutorial/` with many example programs, and an implementation guide under `doc/impl/` which is the document to read for the size and performance claims. The top level of the repository has the `aeneas/` directory for the bootstrap compiler, `apps/` for the utility programs, `bench/` for benchmarks, `bin/` for the built tools, `ci/` for the continuous integration setup, `doc/` for the documentation, `lib/` for the libraries, `rt/` for the runtime system, `start/` for the getting started material, `tasks/` for the task definitions, and `test/` for the tests. Editor support lives in a separate virgil-vscode repository, providing a Visual Studio Code extension with syntax highlighting, semantic highlighting and debugging. The licence is Apache 2.0, and while the repository has no GitHub releases, the last push to the master branch was on 2026-10-18, the day before the current date.

Editorial conclusion

Adopt Virgil if you are writing small, fast programs with few dependencies or doing language and virtual machine research, since the compiler produces standalone native binaries, jars and WebAssembly from one source and the whole toolchain is self-hosted. Do not adopt it for general application development, because it is a research language with a small standard library and no GitHub releases to pin against. Verify first which target you need, since the compiler is cross-compiling in both directions, and read the implementation guide before you rely on the binary size claims, because they depend on whole-program optimisation.

Frequently asked questions

Official sources

1. Issues
2. README
3. titzer/virgil on GitHub