Kalandra: reviving Clio

14 October 2026 · Pouya Eghbali · Development preview 0.13.0

Clio is coming back as Kalandra. The name is new, the implementation has been rebuilt, and the question that started it still matters to me: how much of a distributed application should we have to assemble by hand?

You can try the development preview in the browser today. The compiler and tools are available on npm as @kalandra/cli@0.13.0. This is an early preview, with experimental remote services and room for the language to change.

Try Kalandra Work with the development toolchain

Kalandra 0.13.0 continues the version sequence from Clio 0.12.0. The numbering reflects that history; this is a rebuilt language and toolchain, not a compatibility release.

Where Clio began

In March 2019, I publicly introduced Clio as a functional language targeting distributed systems. It grew out of work that required many remote calls and APIs. Compiling to JavaScript meant it could build on an existing runtime and library ecosystem, in browsers and on servers.

Introducing the Clio programming language — 3 March 2019

Later that month, a reactive to-do app put the idea into practice: server functions exposed over the network, imported by a client, with changes flowing back to the interface. The application was small, but the point was larger: communication between parts of a program could be part of the programming model.

How to Make a Reactive To-do App With Clio — 11 March 2019

By May 2021, my reintroduction of Clio emphasized parallel execution, remote functions, and a language's ability to influence how we build applications. In September, I explored browser workers and the serialization behind parallel calls. Those articles describe earlier versions of Clio, not promises of compatibility or current Kalandra performance.

Reintroducing the Clio programming language — 21 May 2021 Clio: extremely fast, multi-threaded code on the browser — 20 September 2021

Development eventually went quiet. Kalandra is a fresh beginning for those ideas, with .kalandra source files and a rebuilt toolchain.

Why bring it back in 2026?

AI is making code easier to produce. That changes what I want from Kalandra in 2026. Saving a few keystrokes isn't enough.

Kalandra is both a programming language and a framework for building parallel and distributed applications. The language expresses the work; the runtime, service contracts, and tools provide the machinery to run it across workers and services.

I want calling a function on another machine to be a normal part of building an application. Define the function, expose it as a service, import it where it's needed, and call it. Running independent work across CPU cores should be just as straightforward.

Today, that often means assembling worker infrastructure, message handling, serialization, and API clients. Kalandra's goal is to take care of more of that machinery, so distributing work becomes a design choice you can make directly in your program.

When I started Clio in 2018, these were the problems I wanted to solve. In 2026, I still feel that they haven't been solved in the way I hoped. We have better tools, more infrastructure, and AI that can write much of the code, but moving work between a browser, a worker, and a remote machine still too often means building and maintaining the connections ourselves.

There are good solutions to individual parts of this problem. What I still miss is a way of building applications where parallel and distributed execution belong to the programming model from the beginning, rather than becoming another layer of infrastructure to assemble around it.

That's why I'm reviving Clio as Kalandra. I want to keep exploring applications built around functions that can run wherever they're needed, with the framework handling more of the machinery that connects them. The compiler is one piece of that idea. The larger goal is to make this way of thinking about and building applications practical enough to use every day.

What is in this preview?

Kalandra now has a TypeScript compiler built with Chevrotain, emitting JavaScript modules and source maps. It supports functions, pipelines, records, modules, and explicit JavaScript package imports.

Typed parallel calls run through browser workers in the playground and a bounded Bun subprocess pool locally. Nested tasks share the scheduler. The runtime supports cancellation and deadlines.

Experimental Bun services expose typed tasks. Generated client contracts let the compiler check remote imports before execution. Endpoint bindings choose where calls go; authentication and service setup remain explicit.

The toolchain includes project creation, checking, builds, execution, watch mode, formatting, and a language server. The website and guides use Tiramisu Docs, with a browser playground for trying small programs.

Explore parallel calls Run the remote service example

Decisions behind the rebuild

JavaScript remains the compilation target. Kalandra can build on existing engines and packages while concentrating on its execution model.

Worker boundaries require concrete serializable types. An arbitrary dynamic JavaScript value cannot silently cross into a parallel task: the compiler rejects an unsupported call. Sia 2 carries data using generated schemas; Number uses an eight-byte float64 codec to preserve its floating-point behavior.

Remote calls stay visibly asynchronous. A typed contract describes the values crossing the boundary; it cannot make a network reliable. Cancellation, deadlines, endpoint configuration, and failure handling remain part of designing the application.

The revival establishes a working foundation before revisiting the language's rough edges. It is a fresh start, with no legacy migration layer. Some older Clio ideas have been ported, some have limits, and future design changes will be discussed here.

Read the current limits

What comes next

Finish release packaging and distribution, improve the documentation, and use real programs to test the model. Then address the recorded language design flaws and develop new capabilities from that foundation.

The most useful question for this preview is simple: where does expressing a program as local work, parallel tasks, and remote functions make it easier to understand—and where does it still get in the way?