Introduction — From many ideas, a language of its own

From many ideas, a language of its own.

Zolo is a typed, general-purpose programming language for scripts, services, native binaries, WebAssembly, and web applications. Its identity is not a comparison between two other languages. It is the coherent result of several ideas working together: explicit data modeling, pipeline composition, an embeddable runtime, multiple compilation targets, and a toolchain designed as part of the language.

If you want to run code immediately, go to Getting Started. This page explains the shape of the language first.

Why Zolo exists¶

Scripting languages are excellent at getting close to an application, game, editor, server, or device. They often become painful when a script turns into a system: types arrive late, modules are informal, refactors become risky, and editor support can only guess.

Languages with stronger models and tooling solve that problem, but they often give up the small, embeddable runtime and the ability to enter an existing host.

Zolo refuses that tradeoff. It aims to keep the directness of scripting while providing the structure expected from a modern project:

• static types with inference;
• structs, enums, traits, generics, and exhaustive match;
• optional values, Option, Result, and explicit error handling;
• the pipe operator |> and lazy iterators for readable composition;
• decorators, tests, benchmarks, temporal literals, and async features;
• a CLI, formatter, linter, language server, debugger, REPL, package manager, profiler, coverage, and documentation generator;
• an embedded VM, Lua 5.1 output, native backends, and WebAssembly;
• HTTP and Verniz for server-rendered and interactive web applications.

The point is not the length of that list. The point is that these parts share one language model and one source file.

References, not a recipe¶

Zolo does not hide its influences. You may recognize data modeling and pattern matching from Rust and Swift, tooling expectations from TypeScript, embeddability from Lua, pipeline composition from Elixir and F#, and declarative web ideas in Verniz.

Those references help a new reader find familiar landmarks. They do not define the language. Zolo chooses its own semantics, syntax, runtime, diagnostics, build model, and way for these features to compose.

That is what from many ideas, a language of its own means.

The language in one small program¶

const base = 2

/// Multiplies two integers and returns the result.
fn multiply(a: int, b: int) -> int {
    return a * b
}

let result = base |> multiply(2)
print("Hello from Zolo!")
print("2 * 2 = {result}")

Even this small program shows the basic direction: inferred values and explicit function boundaries, documentation attached to declarations, composition that reads left to right, and string interpolation without extra machinery.

Larger programs use the same vocabulary instead of switching to a separate "application mode."

One source, several destinations¶

The source stays Zolo. The command selects how it is delivered.

These paths are not separate dialects. Backend parity is a compiler responsibility: a program should keep the same meaning when its destination changes.

Tooling is part of the language¶

Zolo treats the editing and debugging experience as language behavior, not packaging added after the compiler.

The parser, type checker, diagnostics, formatter, LSP, semantic tokens, code actions, debugger, tests, and backends are expected to agree. When syntax evolves, all of those surfaces must evolve with it.

That principle is visible in the CLI:

zolo run --watch
zolo check --watch
zolo test main.zolo --watch
zolo lint . --fix
zolo fmt main.zolo
zolo dev main.zolo

A language feature is only complete when it works in the editor, the VM, native builds, WebAssembly, documentation, and examples.

Where Zolo fits¶

Zolo is a strong fit for:

• scripts and automation that are growing beyond a single file;
• plugins and extensions for Lua-compatible hosts;
• command-line tools and services that benefit from a standalone native binary;
• browser or edge programs delivered as WebAssembly;
• HTTP services and full-stack web applications with Verniz;
• teaching, prototyping, game scripting, and creative coding where fast iteration still needs structure.

Zolo is not trying to replace systems languages for kernels, drivers, hard real-time software, or allocation-sensitive hot paths. It is also pre-1.0: the compiler and toolchain are active, but APIs can still change and the ecosystem is smaller than mature languages.

Use it for exploration, tools, scripts, plugins, and non-critical applications today. Evaluate the current release carefully before choosing it for production-critical work.

A language that can keep evolving¶

Zolo began close to the Lua ecosystem, but it is no longer only a nicer surface over Lua. The embedded VM, native backends, WebAssembly, project model, package tooling, diagnostics, and Verniz have made it a broader language.

The durable identity is therefore not "Rust syntax" or "Lua lightness." It is this:

• familiar ideas without a borrowed identity;
• composition without hidden control flow;
• types without ceremony everywhere;
• several destinations without several source languages;
• tooling that evolves with the compiler.

Next¶

• Getting Started — install the current toolchain, create a project, and choose a target.
• Zolo by Example — learn from complete, runnable programs.
• Architecture — follow source code through the compiler and its backends.