flix: a JVM language that puts functional, imperative, and logic side by side

One language, not a family of dialects

The README is short, and its first real sentence is the whole pitch: Flix is a statically typed functional, imperative, and logic programming language. That combination is the point. Most languages pick one paradigm and treat the others as awkward guests, and the ones that do support all three tend to bolt them together as separate subsystems. Flix presents them as ordinary syntax choices inside a single compiler.

The repository topics back that up. Alongside the expected functional and programming-language tags sit imperative, logic, jvm, and hacktoberfest. Nothing there suggests a wrapper project or a library that happens to embed an interpreter; `main/` and `build.mill` at the root indicate a self-hosted compiler that you build from source.

The homepage is flix.dev, and the README does something worth respecting here: it says almost nothing and points you there. A research language that dumps its manual into its README usually means the manual is a reference, not a guide. Here the README is a badge wall and an example, and everything else lives on the website.

The README opens with alpha conversion, not hello world

The example code fence in the README is the entire tutorial, and it is not a toy. It defines an enum for the three expressions of the lambda calculus, then writes alpha conversion over it. Variables are integers, so renaming is a map from one integer to another.

enum Expression {
    case Var(Int32),
    case Abs(Int32, Expression),
    case App(Expression, Expression),
}

The function that walks the tree takes an expression and the substitution map built so far:

def alpha(e0: Expression, m: Map[Int32, Int32]): Expression = match e0 {

Inside the variable case there is a nested match that either keeps the name or swaps in the fresh one:

        match Map.get(x, m) {
            case None => Var(x)
            case Some(y) => Var(y)
        }

Three things are on display in about thirty lines. Enums with payload constructors. Pattern matching with nested cases. And recursion that threads state explicitly through a map rather than hiding it in a closure, which is the functional style the compiler clearly supports without insisting on purity everywhere. If you wanted a single fence that told you what writing Flix feels like, this is it.

Examples split along paradigm lines, and datalog gets its own folder

The most useful part of the tree for a newcomer is `examples/`, and the directory names are themselves documentation. There is `functional-style/` and `imperative-style/` as separate folders, which is how a language can genuinely support both without pretending they are the same thing.

Then there are the folders that give away the more unusual features. `effects-and-handlers/` is the algebraic effects implementation, `datalog/` covers the logic programming side, `traits/` covers interface-style dispatch, and `interoperability/` covers talking to Java. `records/`, `structs/`, and `modules/` are the plain data modelling and system split.

Two more folders are telling. `concurrency-and-parallelism/` implies the language makes choices about how work is scheduled rather than leaving it to the JVM defaults. And `tail-recursion-and-termination/` suggests the compiler treats guaranteed termination as a checked property, which is a meaningful design commitment in a language that also allows mutation and effects. `unsorted/` is presumably where the experiments live that do not fit a category yet.

Mill drives the build, and BUILD.md is the only build documentation

Build tooling is where JVM language projects usually converge on Gradle or sbt. Flix does not. The root of the tree holds `build.mill`, a `mill` launcher script, `mill.bat` for Windows, `.mill-version`, and `.mill-jvm-opts`, which is the shape of a Mill project down to the pinned tool version and the JVM options file.

None of those files are shown in the README. The README's entire build section is a link to docs/BUILD.md and nothing else, which means you cannot build the compiler from the README page. You have to go read a document in the repository before your first compile.

That is a defensible choice for a project whose users are language implementers rather than application developers, and it has one real side effect. Anyone who just wants to try Flix cannot reach a REPL or a build without first reading a separate guide. There is no `flix new`, no one-line install, and no hello world you can type into a terminal, at least not from anything the README shows.

The 0.76 releases are compiler-internals work, not language changes

The three most recent releases are worth reading as a group because they tell you where the maintainers are spending attention. None of them add syntax. All of them work on the compiler's internals.

Version 0.76.0, published on 2026-09-13, is the substantial one. It adds support for building the compiler as a Graal native image, reimplements bytecode generation to use nominal class descriptors, reimplements Java resolution to read class files without loading them, and lists assorted performance improvements. The last two are related: if you can resolve Java types by reading class files off disk instead of loading classes through the classloader, you skip a lot of work and you get far more headroom for a native image build.

Version 0.76.1 on 2026-09-16 restructures the LSP internals, and 0.76.2 on 2026-09-20 restructures package management internals. Both credit the same contributor. The presence of an LSP at all is the quiet signal here: a language that is only theoretically interesting has no language server. The last push to master was on 2026-09-23.

What the repository settles and what flix.dev has to answer

Reading what is actually here gives you a fair picture of the project's centre of gravity. It is a compiler that builds itself, with an effects implementation, a Datalog engine, a language server, and a packaging system, all worked on in the same month. The Apache 2.0 licence is stated plainly in the README, and JetBrains IntelliJ IDEA plus JProfiler from EJ Technologies are credited as sponsor tooling. The project also carries a Hacktoberfest topic, which suggests it takes outside contributions.

What the repository does not settle is anything about the language itself. There is no syntax reference, no standard library documentation, no type system description, and no performance notes. Every one of those lives on flix.dev. The README's one example shows you what the code looks like, not what the whole language can express, and an alpha conversion routine happens to use only a small slice of it.

So the honest split is this. The repository is convincing evidence that Flix is a serious piece of compiler engineering with a real feature set under construction. It is not evidence that you could adopt the language next month, because the documentation a user needs is not in the repository at all.

Editorial conclusion

Flix is worth reading as a compiler project rather than as a language you would adopt this quarter. The example directories map one to one onto the paradigms the README claims, the effect handlers and Datalog support are real enough to browse, and the 0.76.0 work on Graal native images and class file reading shows the runtime side is being taken seriously. The catch is that the README is a signpost, not a manual: one line about the language, one lambda calculus example, one link to docs/BUILD.md. If you want to know what Flix means by a feature, flix.dev is the only place the answer lives, and the build is Mill rather than Gradle or sbt, which is one more thing to learn before you compile anything.

Frequently asked questions

Official sources

1. flix/flix on GitHub
2. Issues
3. Project website
4. README
5. Releases