Programming lost its way.
We're taking it back.
FezLang is a new language built on an old truth: code should be obvious. Not clever. Not abstract. Not buried inside objects you can't see. In the era where AI writes code and humans read it, clarity isn't a feature — it's the whole point.
curl -sSL https://fezlang.org/install.sh | sh
This is what clarity looks like
No class hierarchies. No monadic types. No inheritance. Read it top to bottom and you know everything.
FezLangstruct User {
name: str
email: str
}
module auth {
const MIN_PASS = 8
fn signup(name: str, email: str, pass: str) -> User, err {
if str.len(pass) < MIN_PASS {
return User{}, error("password too short")
}
hash = crypto.sha256(pass)
user = User { name: name, email: email }
defer log.info("signup attempt: {email}")
return user, nil
}
}
user, err = auth.signup("Cal", "cal@fez.dev", "s3cret123")
if err {
io.print(err.message)
}
io.print("Welcome, {user.name}!")
Count the concepts: struct, module, fn, const, if, defer, return. Seven keywords to build a complete feature.
Why FezLang
Modules
The organizing unit. Nestable, dot-accessible. Not objects. Not packages tied to directories. Pure structure in the language itself.
Functions
The working unit. First-class, passable, composable. No hidden this, no implicit receivers, no side effects you can't see.
Structs
The data unit. Plain containers with named fields. No methods, no constructors, no destructors. Data is data.
Built for the era where AI writes and humans read
The way we write software has changed. AI writes the code now. Your job isn't typing — it's reviewing.
When AI writes OOP code, you get AbstractUserServiceFactory with inheritance chains and hidden state. Your 2-minute review becomes a 20-minute investigation.
FezLang code — whether written by a human or an AI — is reviewable in seconds. Every function takes its data as arguments and returns results. No hidden state. No this. No inheritance. You read top to bottom and you know everything.
From scripts to systems
Most languages pick a lane. Go does applications. Rust does systems. Python does scripts. Fez spans the full spectrum.
import "file"
import "str"
lines = file.read_lines("data.csv")
for line in lines {
cols = str.split(line, ",")
name = cols[0]
score = cols[1]
io.print("{name}: {score}")
}
#memory manual
import "sys"
struct GpioPin {
addr: int
mode: byte
}
fn write_pin(pin: ref GpioPin, val: byte) {
base = sys.mmap(pin.addr, 4096)
ptr = sys.ptr_offset(base, 0x13)
sys.write_byte(ptr, val)
sys.munmap(base, 4096)
}
pin = GpioPin { addr: 0x3F200000, mode: 1 }
write_pin(ref pin, 0xFF)
Same modules. Same functions. Same structs. Same dot syntax. One language, one mental model.
Fez vs every paradigm
OOP says
"Model the world as objects. Inherit behavior. Encapsulate state. Use polymorphism to handle variation."
Result: AbstractUserServiceFactoryProvider, 6 levels of inheritance, and a 45-minute debugging session to find which this is calling which.
Fez says
"Structs hold data. Functions do work. Modules organize. The dot is always a path, never a method call."
Result: You read auth.signup(name, email, pass) and you know exactly what's happening, where the data comes from, and where it goes.
FP says
"Everything is a function. Compose them. Use monads for side effects. Types should be algebraic."
Result: IO (Either ParseError (Maybe (Reader Config (Writer [Log] User)))). Correct. Unreadable. Requires a PhD to review.
Fez says
"Functions are first-class. Errors are values. Types are simple. You don't need category theory to write a web server."
Result: user, err = auth.signup(name, email, pass). Two values. Check the error. Move on.
Procedural says
"Just write functions. Call them in order. Keep it simple."
Result: 10,000-line files with global state, no namespacing, and function names like process_data_final_v2_fixed.
Fez says
"Functions are right. But organization matters. Modules give you structure without the overhead of objects."
Result: module auth { fn signup(...) } — organized, namespaced, no globals needed.
Data-Oriented says
"Separate data from behavior. Think about how data flows, not about objects."
Result: The separation was right. But without modules as a language construct, you end up with ad-hoc organization.
Fez says
"Data-Oriented got it half right. Separate data and behavior — then add modules for the organization it was missing."
Result: Structs for data. Functions for behavior. Modules for organization. The complete picture.
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."
— Antoine de Saint-Exupéry, Wind, Sand and Stars (1939)