EzLang - a systems language aiming to make native software easier to write

Repo: https://github.com/ZYF93/EzLang

EzLang is an experimental systems programming language built around a simple idea: native software should be fast and reliable, but it should not require every small program to carry a heavy mental model.

The project is still early. It is a compiler and language-design experiment, not a production language. I am sharing it because I want feedback from people who care about compilers, memory models, cross-platform tooling, and whether this direction is worth pushing further.

What EzLang is trying to be

EzLang aims to sit in the space between scripting-language ergonomics and systems-language output.

The goals are:

• Fewer memory pitfalls without giving up speed.


• One codebase that can target native platforms, mobile platforms, and WebAssembly.


• Code that reads close to intent, with expression-first syntax and named calls.


• A language simple enough that AI-generated code is still easy for humans to review and maintain.


• A practical systems language with the compiler, formatter, LSP, VS Code extension, package/project workflow, and docs developed together.

This is not meant to replace C, Rust, Zig, Go, or Swift. It is an attempt to test a different set of tradeoffs: can a small language make systems programming feel lighter while still compiling down to efficient native output?

A small example

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 = "copied value={}", args = args));

    return copied.val == 42 ? 0 : 1;

};

The syntax is expression-oriented, calls use names where clarity helps, and values are copied by default. The language leans toward explicit, readable code rather than dense cleverness.

The memory model direction

The current design combines value semantics with an Arena-style memory model. Temporary aggregate values can be reclaimed with scope-like lifetimes, while weak references are explicit in the type system.

The ambition is simple: make common memory mistakes harder to write, without asking developers to think about ownership annotations in every line of code.

This part needs the most scrutiny. Escape analysis, diagnostics, and negative tests need to become much stronger before the design can claim real safety.

Cross-platform goal

EzLang is being designed with multiple targets in mind:

• native executables


• mobile platforms


• WebAssembly / emcc-style targets

The standard library is intended to expose consistent interfaces across these targets where that makes sense. The current repository already includes the project CLI, formatter, LSP, VS Code extension, and standard-library direction, but the cross-platform story is still incomplete.

AI and maintainability

One motivation for EzLang is the world we are already entering: more code will be drafted by AI.

That makes the human side more important, not less. A language that is friendly to AI but hostile to human review is not a good outcome. EzLang tries to keep syntax and semantics explicit enough that a human can quickly inspect generated code, understand what it is doing, and safely change it.

This has affected small choices: named arguments, expression-first composition, less hidden magic, and a preference for code that reads like a direct description of intent.

Current implementation

The compiler is currently written in Python and uses ANTLR plus llvmlite:

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

What exists today:

• Parser and semantic-analysis pipeline.


• LLVM IR generation for demo programs.


• 
  ez init, ez build, ez run, ez test, and ez fmt.


• Structs, generics, optional types, union types, function types, named calls, and type aliases.


• 
  extern "..." for target plus declare for ABI bindings.


• Early flow {}, parallel {}, and race(pl) concurrency hooks.


• Formatter, LSP, VS Code extension, bilingual docs, and examples.

What is rough:

• The language spec is not stable.


• Memory-safety guarantees are not proven.


• Error messages need work.


• The runtime is tiny.


• Cross-platform behavior is incomplete.


• The standard library is still more of a map than a mature library.

What I would like feedback on

• Is the value-semantics plus Arena direction worth pursuing?


• Does this mental model feel meaningfully simpler, or just different?


• Are named calls a good readability tradeoff in a systems language?


• What tests would make the memory model more credible?


• Which small real-world program should EzLang try to compile first?

I am not looking for hype. I am looking for sharp feedback, broken assumptions, small test cases, and criticism from people who have built or used serious language tooling.