Everyone. But especially you if you're just starting out.

The Primary Audience

Beginners

EZ was built with you in mind first. If you've never written code before, EZ is designed to be your first language. The syntax reads like English, error messages explain what went wrong, and there's no hidden complexity waiting to trip you up.

You don't need:

• A computer science degree
• Prior programming experience
• Knowledge of "design patterns"
• Understanding of memory management

You just need curiosity and willingness to learn.

Hobbyists

Want to automate something? Build a small tool? Tinker with code on weekends? EZ is perfect for projects where you want to get things done without fighting your tools.

Experienced Developers

If you're tired of complexity, EZ might be refreshing. No frameworks to configure. No dependency trees to manage. No implicit behavior to debug. Just explicit, predictable code.

Experienced developers can unlock EZ's full power. The high skill ceiling means there's depth here if you want it.

Educators and Students

Teaching programming? EZ's clarity makes concepts visible. Students can focus on learning to think like a programmer instead of memorizing syntax quirks.

What Can You Build With EZ?

Right Now

• Scripts — Automate tasks, process files, transform data
• CLI tools — Build command-line utilities
• Small to medium projects — Applications that don't need enterprise scale
• Learning projects — The best way to learn is by building

The Future

The goal is for EZ to grow into a language capable of:

• Systems programming
• Production applications
• Larger-scale software

This is the dream I am working toward.

What Do You Need to Know Before Starting?

Technical Requirements

• A computer (Windows, macOS, or Linux)
• Internet connection (to download EZ and read docs)

That's it.

Language Requirements

EZ's syntax is designed to read like plain English. You don't need to be a native English speaker — if you can read this page, you can read EZ code.

The documentation was tested with non-native English speakers and they understood it. If you're proficient enough in English to navigate daily life, you're proficient enough to learn EZ.

Prior Programming Experience

Not required.

EZ is designed to be approachable for people who have never written a line of code. If you DO have experience, great — you'll pick it up even faster.

Who Might EZ NOT Be For?

Right Now

If you need to build something that requires:

• High-performance computing (use Rust or C)
• Mobile apps (use Swift, Kotlin)
• Web frontends (use JavaScript)
• Machine learning (use Python)

...then EZ isn't the right tool today. EZ is focused on being great at what it does, not being mediocre at everything.

Philosophically

If you:

• Love OOP and class hierarchies
• Want a massive ecosystem of packages
• Prefer implicit over explicit behavior
• Think complexity equals power

...you might not vibe with EZ's philosophy. And that's okay; use what works for you.

The Bottom Line

EZ is for anyone who wants to learn programming or wants a simpler way to write code.

Beginner? Start here. Expert? Try something different. Curious? Give it a shot.

---

Is EZ compiled or interpreted?

Right now: Interpreted.

The goal: Compiled (v2.0).

Current State

EZ is currently an interpreted language. The interpreter is written in Go and executes your code directly

ez myprogram.ez    # Runs immediately

This means:

• Fast iteration — change code, run it, see results
• No build step to wait for
• Easy to get started

The Future: Compilation

The goal is to one day add compilation. This would let you:

ez build myprogram.ez -o myprogram    # Compile to binary
./myprogram                            # Run standalone

Benefits of compilation:

• Single binary distribution — Give someone one file, it just works
• Better performance — Native code runs faster than interpretation
• Cross-compilation — Build for any platform from any platform
• Production-ready — Deploy without requiring EZ to be installed

Why Start Interpreted?

It was easier.

Building an interpreter is significantly simpler than building a compiler. Starting interpreted allowed me to:

• Nail down the language design
• Iterate quickly on features
• Get something working and usable

Many successful languages followed this path — prove the language works, then optimize.

Will Both Modes Exist?

Honestly? I'm not sure yet.

The path forward will become more clear later on down the line. Right now, the focus is on making this version solid.

---

Why does EZ use unique keywords?

EZ uses keywords like do, temp, as_long_as, and or/otherwise instead of the traditional func, let, while, and else if/else. This is intentional.

The Short Answer

This is how code reads in plain English. When you read EZ code, it should sound like describing what the program does to another person.

The Philosophy

When experienced programmers read code, their brain translates it into plain language anyway:

// What you see in most languages:
while (x < 10) { ... }

// What your brain thinks:
"As long as x is less than 10, do this..."

EZ just writes it the way your brain already reads it:

as_long_as x < 10 { ... }

If that's how we think about code, why not write it that way?

The Unique Keywords

do instead of func / function / def

do greet(name string) {
    println("Hello, " + name)
}

Read it out loud: "Do greet with name string..."

It's an action. A verb. You're telling the computer to do something.

temp instead of let / var

temp count int = 0

Read it: "Temporary count, an integer, equals zero."

It's a temporary value — it can change. The name says what it is.

as_long_as instead of while

as_long_as count < 10 {
    count += 1
}

Read it: "As long as count is less than 10, do this."

That's exactly what a while loop does. Now the code says it.

or / otherwise instead of else if / else

if score >= 90 {
    println("A")
} or score >= 80 {
    println("B")
} or score >= 70 {
    println("C")
} otherwise {
    println("F")
}

Read it: "If score is at least 90, print A. Or if score is at least 80, print B. Or if score is at least 70, print C. Otherwise, print F."

That's plain English. No weird else if construction.

Keywords That Stay The Same

Some keywords are intentionally the same as other languages:

EZ	Same As	Why
break	C, Go, Rust, Python	Universal concept
continue	C, Go, Rust, Python	Universal concept
if	Everything	It's already plain English
for	Most languages	Familiar iteration
return	Everything	Universal concept
const	C, Go, JavaScript	Established meaning
struct	C, Go, Rust	Established meaning
import	Most languages	Familiar concept

Why Keep Some Keywords Standard?

Beginners won't stay beginners forever.

One day, EZ learners will move on to other languages — Go, Rust, C, Python, whatever calls to them. When they do, I want them to recognize concepts:

• "Oh, this language has break and continue too! EZ taught me those."
• "This language uses else if instead of or, but I know what it means — I'll just read it as 'or' in my head."
• "Structs work the same way here!"

EZ teaches transferable concepts with approachable syntax. The goal isn't to trap you in EZ — it's to give you a foundation that makes learning other languages easier.

The Balance

EZ strikes a balance:

Keyword Type	Examples	Philosophy
Unique to EZ	do, temp, as_long_as, or, otherwise	Plain English readability
Standard	if, for, break, continue, return, const, struct	Transferable knowledge

The unique keywords make EZ readable. The standard keywords make your knowledge portable.

Reading Other Languages After EZ (Example of Go Code)

After learning EZ, when you see this in Go:

func greet(name string) {
    fmt.Println("Hello, " + name)
}

x := 0
for x < 10 {
    x++
}

if score >= 90 {
    fmt.Println("A")
} else if score >= 80 {
    fmt.Println("B")
} else {
    fmt.Println("F")
}

Your brain will read:

• func → "Oh, that's like do"
• for x < 10 → "That's like as_long_as"
• else if → "That's just or"
• else → "That's otherwise"

You'll understand it instantly because you learned the concepts, not just the syntax.

---

Why doesn't EZ have OOP?

EZ is intentionally anti-OOP. No classes. No inheritance. No this or self. This is a deliberate design choice, not a limitation.

The Short Answer

Data is data. Use structs and variables. You don't need a class hierarchy to write good software.

The Problems with OOP

1. Unnecessary Complexity

OOP introduces concepts that get in the way of actually learning to program:

• Class hierarchies and inheritance chains
• Abstract classes vs interfaces vs traits
• Polymorphism, encapsulation, abstraction (the "pillars")
• Constructor overloading, method overriding, visibility modifiers

2. Confusing Syntax (Example of Python Code)

# What even is self?
class Person:
    def __init__(self, name):
        self.name = name  # Why self? Why twice?

    def greet(self):
        print(f"Hi, I'm {self.name}")

Compare to EZ:

const Person struct {
    name string
}

do greet(p Person) {
    println("Hi, I'm ${p.name}")
}

No self. No this. No magic. Just data and functions.

3. Hidden Behavior

OOP encourages hiding behavior inside objects. EZ encourages making behavior explicit. When you call a function in EZ, you can see exactly what it takes and what it returns. No surprises.

"But OOP is the Industry Standard!"

EZ isn't trying to replace your favorite language. If you love Python or Java, use them. EZ exists for people who want to try something different — explicit simplicity without the baggage.

Standards change. Good ideas don't need a committee to validate them.

What EZ Offers Instead

Structs for Data

const User struct {
    name string,
    email string,
    age int
}

temp user User = User{name: "Alice", email: "alice@example.com", age: 30}

Functions for Behavior

do validate_user(u User) -> error {
    if len(u.name) == 0 {
        return error("name cannot be empty")
    }
    if u.age < 0 {
        return error("age cannot be negative")
    }
    return nil
}

Modules for Organization

Got a lot of types? Put them in their own file:

myproject/
├── main.ez
└── types/
    └── user.ez      # module types

// types/user.ez
module types

const User struct {
    name string,
    email string
}

// main.ez
import types

do main() {
    temp u types.User = types.User{name: "Alice", email: "a@b.com"}
}

No cyclical imports. No dependency injection frameworks. Just organize your code like files in folders.

What I Want You to Learn

If you're a beginner: Learn to program. Learn the basics. Learn to read error messages. Learn that it's okay to make mistakes — that's how you get better. Don't let anyone convince you that you need to understand "object-oriented design patterns" before you can write useful code.

If you're experienced: Remember that not everyone has your background. Clarity matters. Documentation matters. Design decisions that seem obvious to you are often confusing to others. EZ tries to be clear to everyone.

The Philosophy

Why can't things be easy? Why do we accept confusing documentation, implicit behavior, and unnecessary complexity as normal?

EZ rejects that. The language reads like English. The docs follow a clear path. The error messages tell you what's wrong and how to fix it.

Software doesn't have to be a guessing game.

---

Why doesn't EZ have a package manager?

EZ has no package manager. No ez install. No ez add. No dependency hell. This is permanent and by design.

The Short Answer

The language is the only tool you need. Write your own code, use the stdlib, or copy what you find. That's it.

The Problems with Package Managers

1. Tool Fragmentation

JavaScript alone has npm, pnpm, npx, yarn, bun...

Every language seems to spawn multiple competing package managers, each with their own commands, config files, and quirks. You end up spending more time managing tools than writing code.

EZ has one tool: ez. That's it.

2. Security Nightmares

Every package you install is code you didn't write running on your machine. Supply chain attacks are real:

• Malicious packages with typosquatted names
• Compromised maintainer accounts
• Dependency confusion attacks
• Packages that suddenly disappear, breaking everything

When you write your own code or use the stdlib, you know exactly what's running.

3. Dependency Hell

my-project depends on A@2.0
A@2.0 depends on B@1.5
B@1.5 depends on C@3.0
C@3.0 conflicts with D@2.0 which you also need

Hours wasted. Lockfiles that don't lock. Version conflicts that make no sense. We've all been there.

4. The node_modules Problem

my-project/
└── node_modules/    # 500MB for a todo app
    └── ... 1,847 packages

No thanks.

How EZ Handles Dependencies

It doesn't. EZ has no external dependencies. You have:

1. The stdlib — Built into the language. Always available. Always works.
2. Your own code — Write what you need. You'll understand it better anyway.
3. Modules — Organize your own code into files and directories.

That's the complete list.

"But What If I Need External Code?"

You have options:

1. Write it yourself — This is how you actually learn. And you'll know exactly how it works.

2. Find it and copy it — Someone wrote a function that does what you need? Copy the code into your project. It's yours now. No dependency, no breaking changes, no supply chain risk.

3. Suggest it for the stdlib — If it's generally useful, propose it. Send a patch. If it fits EZ's philosophy, it might get added for everyone.

4. Have AI write it — We're in 2025. Describe what you need, provide the EZ documentation as context, get working code, understand it, own it.

The C/Odin Philosophy

Think about C and Odin. A C or Odin developer doesn't reach for a package manager when they need something:

• "I need to parse JSON" → Find a header file/Use the Odin JSON package, or write it yourself
• "I need to make HTTP requests" → Find a library/package, or use system calls

C has been around for 50+ years and built operating systems, databases, and games without a package manager. You can too.

What About EZ's Own Source Code?

EZ is written in Go. The goal is for EZ's source code itself to have zero external Go dependencies — only Go's standard library. If something isn't in Go's stdlib, I'll include it directly in EZ's source.

The language depends only on itself. The programmer depends only on the language.

Will EZ Ever Have a Package Manager?

No.

This isn't "not yet" or "maybe later." This is a permanent, philosophical stance. Package managers encourage:

• Not understanding your dependencies
• Trusting strangers' code blindly
• Bloated projects with hundreds of transitive dependencies
• Security vulnerabilities you don't even know exist

EZ rejects all of this.

What You Gain

• Simplicity — One tool, no ecosystem to learn
• Security — No supply chain attacks
• Understanding — You know every line of code in your project
• Stability — No breaking changes from upstream
• Speed — No downloading, no resolving, no waiting

The Philosophy

The only things you need to write EZ code is EZ, a computer, and your brain. No account signups. No package registries. No finding out a critical dependency has stopped being maintained.

Just you and the language.

---

EZ uses a simple memory model that varies by type, similar to Python, JavaScript, and other beginner-friendly languages. This means you already get what pointers provide in other languages without the complexity.

Semantics by Type

Type          On Assignment         In Functions
─────────────────────────────────────────────────────────────────
Primitives    Copy (independent)    Copy (independent)
Strings       Copy (independent)    Copy (independent)
Arrays        Reference (shared)    Read-only by default, mutable with &
Maps          Reference (shared)    Read-only by default, mutable with &
Structs       Reference (shared)    Read-only by default, mutable with &

Primitives include int, float, bool, char, and byte.

What this means in practice

Primitives and strings are copied when assigned or passed to functions:

temp x int = 10
temp y int = x
y = 20
// x is still 10

Arrays, maps, and structs are shared when assigned:

temp a [int] = {1, 2, 3}
temp b [int] = a
b[0] = 100
// a[0] is now also 100 — they share the same data

In functions, parameters are read-only by default. Use & to allow modification:

do birthday(&p Person) {   // & allows modification
    p.age = p.age + 1
}

do get_name(p Person) -> string {   // no & = read-only
    // p.age = 100  // ERROR: cannot modify
    return p.name
}

temp person Person = Person{name: "Alice", age: 30}
birthday(person)  // OK: person.age is now 31

What pointers would add

The only thing explicit pointers add in languages like Go or C is the ability to choose between value semantics (copying) and reference semantics (sharing). Since EZ already has reference semantics for complex types, EZ provides a copy() builtin for when you want an independent copy:

temp a Person = Person{name: "Alice", age: 30}
temp b Person = copy(a)  // independent deep copy
b.age = 31
// a.age is still 30

Why this design?

1. Simplicity — Pointers are a notorious source of confusion for beginners. EZ's model is easier to reason about.
2. No added capability — In an interpreted language without manual memory management, explicit pointers don't give you anything you can't already do.
3. Proven model — This is how the most popular beginner-friendly languages work, and it scales to real applications.

Recursive Data Structures

EZ supports recursive data structures naturally. A struct field typed as its own struct defaults to nil:

const Node struct {
    value int
    next Node  // defaults to nil
}

temp n1 Node = Node{value: 1, next: nil}
temp n2 Node = Node{value: 2, next: nil}
n1.next = n2  // linked list works

If you're coming from C or Go and miss pointers, you probably just need copy().