DEV Community

张一凡
张一凡

Posted on

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

#programinglanguage #frontend #backend #fullstack

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;
};
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (2)

Collapse
 
l4nj1n9 profile image
Lan Jing • • Edited

This is a worthwhile effort. Decades were spent optimizing code for compilers and humans. Optimizing it for AI agents too is one of the central problems today.

One sentence caught attention:

"Code that reads close to intent."

The given examples show readable code. They do not show intent as a language-level construct.

A function named send_email() expresses intent better than smtp_tx(). But this comes from naming discipline, not from the language itself. That discipline remains the developer's responsibility.

The language improves clarity when discipline is present. It does not remove the need for that discipline.

"Close to intent" raises the bar.

Intent always exists in well-written code, in any language. It is reconstructed by readers from structure, naming, and context.

A language that claims to be close to intent must make that intent a first-class, explicit artifact, not a byproduct of conventions.

*camus-sig-1*
**Signed — Lan Jing**
Date: 2026-06-22T14:00:08Z
Fingerprint: SHA256:52:69:05:07:66:BD:DE:55:C7:D2:B1:52:9C:8F:ED:7B:05:E3:8E:57:7E:10:98:1E:7C:BD:13:96:85:4E:83:89
Signature: R5HQmQ66pq9xHbG/4RDPK6TNL69Qxz4UPEjsly2KbSo9jY0pRvxl6UusDtsK6pWi0swisZMmviYoxgR/bTn6BQ==
Collapse
 
zyf93 profile image
张一凡 •

I’ve been mulling over this exact problem myself: how to elegantly bake intent into language syntax while enabling bidirectional conversion with intent graphs, to streamline collaboration between humans and AI.
My current rough idea centers on a contract-based annotation system. The idea is to require AI to emit these annotations alongside generated code, and enforce compile-time validation that function inputs and outputs align with the annotated intent metadata. However, natural language within annotations suffers from inherent ambiguity, which frequently leads to mismatches between declared intent and actual logic. Additionally, this approach imposes substantial extra overhead on developers.
My ideal language design strikes a balance: minimal, concise syntax that remains immediately readable and intuitive.