EzLang - a small systems language I built in a month with AI

I spent the last month building a small programming language called EzLang.

It is an expression-oriented systems language with default value semantics, an Arena-style memory model, LLVM IR generation, a small Flow concurrency experiment, a CLI, formatter, LSP, VS Code extension, and bilingual docs.

This is not production-ready. It is a demo compiler and language-design experiment. I am posting it here because I would like sharper feedback from people who care about compilers, runtimes, type systems, and language tooling.

Why I built it

I wanted to explore a specific combination of ideas:

Systems-level output without making ownership syntax dominate every small program.
Value semantics by default.
Compiler-managed Arena allocation for temporary aggregates.
Named arguments and expression-first syntax for readability.
A small concurrency model that can lower to native runtimes and emcc/Wasm-like targets.
Tooling from day one, not after the language is "done".

None of these ideas are new. The interesting part, at least to me, is whether they can fit together in a small language that still feels practical.

What it looks like

from "std/fmt" import { format, toString };
from "std/io" import { println };

struct Data {
    val: I32;
};

const create = (seed: I32): Data => {
    const d = Data(val = seed + 32);
    return d;
};

const main = (): I32 => {
    const created = create(seed = 10);
    const copied = created;
    const args: Str[] = [toString<I32>(value = copied.val)];

    println(msg = format(template = "arena: copied value={}", args = args));
    return copied.val == 42 ? 0 : 1;
};

The implementation is conventional:

.ez source -> ANTLR parser -> semantic analysis -> LLVM IR -> object/executable

The compiler is currently written in Python and uses llvmlite for LLVM IR generation.

What works today

Parser and semantic-analysis pipeline.
LLVM IR generation for demo programs.
Native examples.
ez init, ez build, ez run, ez test, ez fmt.
Structs, generics, optional types, union types, function types, named calls, type aliases.
extern "..." for target plus declare for platform ABI bindings.
Early flow {}, parallel {}, and race(pl) runtime hooks.
Formatter, LSP, VS Code extension, and docs.

What does not work well yet

The language spec is not stable.
The Arena model needs much stronger escape analysis and negative tests.
Error messages are rough.
The runtime is intentionally tiny.
Cross-platform behavior is incomplete.
The standard library is more of a design map than a mature library.

I used AI heavily while building this. It was useful for boilerplate, tests, docs, and first-pass implementations, but it also made it very easy to generate plausible compiler code that was subtly wrong. The main lesson was that AI speeds up typing, not language design.

What I want feedback on

Is the Arena/value-semantics direction worth pursuing?
Is flow {} a useful abstraction, or just another async-shaped trap?
Are named arguments everywhere a good tradeoff for a systems language?
Should this stay Python-based while iterating, or move toward a lower-level/self-hosted compiler later?
What small benchmark or test suite would make the project more credible?

Stars are useful because they help me find people interested in pushing the project past demo status. More useful than stars: issues, design criticism, compiler tests, runtime feedback, and small programs that break the current assumptions.

推荐订阅源