Frequently Asked Questions

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

Beginners

EZ was built with you in mind first. The syntax reads like English, error messages explain what went wrong, and there's no hidden complexity waiting to trip you up.

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 hidden behavior to debug. Just explicit, predictable code.

What Can You Build?

• 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

Who Might EZ NOT Be For?

If you need high-performance computing, mobile apps, web frontends, or machine learning — EZ isn't the right tool today. EZ is focused on being great at what it does, not being mediocre at everything.

If you love OOP and class hierarchies, want a massive package ecosystem, or prefer implicit over explicit behavior — you might not vibe with EZ's philosophy. And that's okay.

---

Interpreted.

How It Works

EZ is 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

Why Interpreted?

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.

---

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.

The Balance

Not everything is different. Some keywords are the same as other languages because they're already clear:

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. Beginners won't stay beginners forever — when they move to Go, Rust, or Python, they'll recognize the shared concepts.

---

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

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

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.

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.

---

EZ has no package manager. No ez install. No ez add. No dependency hell. This is 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.

Why Not?

Security

Every package you install is code you didn't write running on your machine. Supply chain attacks are real — malicious packages, compromised maintainer accounts, dependency confusion attacks. When you write your own code or use the stdlib, you know exactly what's running.

Complexity

Package managers bring tool fragmentation, lockfiles, version conflicts, and transitive dependency trees. EZ has one tool: ez. That's it.

Understanding

When you write code yourself, you understand it. When you pull in a dependency, you're trusting a black box. EZ encourages you to own your code.

How EZ Handles It

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.
4. Copy what you find — Someone wrote a function that does what you need? Copy it into your project. No dependency, no breaking changes.
5. Suggest it for the stdlib — If it's generally useful, propose it. If it fits EZ's philosophy, it might get added for everyone.

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

---

EZ uses a simple memory model with copy-by-default semantics. This means you already get what pointers provide in other languages without the complexity.

Semantics

On Assignment         In Functions
─────────────────────────────────────────────────────────────────
Copy (independent)    Read-only by default, mutable with &

All types — primitives, strings, arrays, maps, and structs — are copied when assigned. This gives you independent data by default.

What this means in practice

All assignments create independent copies:

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

temp a [int] = {1, 2, 3}
temp b [int] = a
b[0] = 100
// a[0] is still 1 — they are independent copies

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). EZ provides this choice through two builtins:

• copy() — Explicit deep copy (same as default assignment, but clearer intent)
• ref() — Create a reference for shared data

temp a Person = Person{name: "Alice", age: 30}

// Copy (default behavior)
temp b Person = a          // independent copy
temp c Person = copy(a)    // also independent copy (explicit)
b.age = 31
// a.age is still 30

// Reference (shared data)
temp d Person = ref(a)     // d references the same data as a
d.age = 40
// a.age is now 40 — they share the same data

Use ref() when you need multiple variables to share and modify the same data.

Why this design?

1. Simplicity — Pointers are a notorious source of confusion for beginners. Copy-by-default is easier to reason about.
2. Predictable — No surprises from accidental sharing. You always know when data is shared because you explicitly used ref().
3. Full control — When you do need shared data, ref() gives you that capability without pointer syntax.
4. Proven model — This approach combines the best of value semantics with opt-in sharing when needed.

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 have ref() for shared data and copy() for explicit copies.