Why I created Ori — and how I am creating it

Chapters

Where I came from

My background is in Marketing and Design. I went through prepress, internal marketing and IT support, and the code I wrote amounted to CRUDs in PHP and Ruby. Nothing suggesting “one day this guy will design a programming language.”

What I had — and still have — is a curiosity that never switches off. I like understanding how things work underneath, and I have that classic hyperfocus of someone who learns things completely outside their own field just because something caught their attention. When I started building software alongside AI, the “I only know the basics” ceiling cracked: suddenly I could carry much bigger ideas to the finish line, as long as I knew how to ask the right questions and judge the answers.

Ori was born from that place. Not from a language lab, but from someone who read far more code than they wrote — and was bothered by it.

Before Ori: Zenith, C and Auk9

Ori was not the first attempt — it was the third one that survived. When I started, the language was called Zenith Language, and the first version was written in C. It made sense at the time: systems languages are written in C, right? Wrong for my case. I spent more time hunting memory bugs — dangling pointers, double frees, silent corruption — than designing the language itself. C’s memory particularities charged a price I could not pay: every new idea came with a week of debugging that taught nothing about languages, only about survival in C.

Then came Auk9, already in Rust — and it was also discarded as a product. But discarding was not losing: several Auk9 concepts survived and live in Ori today. That is where I understood something important: throwing away a version can be progress, as long as the learned concepts travel along.

The most honest point: I started understanding almost nothing about how a language works under the hood — explicitly, I mean. I used languages, I did not understand languages. It was by asking questions, one after another, that the path appeared: reading about compilers, memory management and architecture, runtimes, lexers, parsers. Each question pulled another. To this day I may not know 100% of every line of developed code, but I understand much of the machinery — enough to follow conversations about how languages work and even “scratch the surface” in them. For someone who came from CRUD in PHP, that is quite a trip already.

Why create a language

The question that has chased me for years is simple: why does almost every language optimize for the writer, when we spend far more time reading? Each syntactic shortcut seems harmless alone. But add up hundreds of them in a real project and reading turns into decoding. For newcomers, for people with ADHD who need explicit structure, for a code agent that must understand a module without loading the whole repository — the bill arrives.

At first I thought it was just a matter of style. The more I looked, the more it seemed like an architecture problem of the language itself: readability is not cosmetic, it is the most-used interface of the system. And almost nobody designs a language starting from it.

I also wanted to answer a second question: how far can a person from outside the field — with AI as a partner — take the design of a serious language? Ori is that experiment too.

What Ori is — and what it isn’t

Ori is a reading-first language, explicitly typed, compiled to native code (AOT), with its compiler written in Rust. Reading an Ori program should feel like reading a specification: names that say what they do, little magic, visible flow.

What it isn’t: it is not an attempt to replace Rust, Go or any established language. It is not a product competing in the market. It exists for compiler study, for AI-assisted programming, and for readability — including for brains that work like mine. That honesty about scope frees me to make unpopular decisions when they serve reading.

And there is the motive above all technical ones: I do not want to create a product, nor anything for the market. I want to make something that makes me happy — creating my experiments, playing with the tools and, throughout this whole journey, learning and having fun. If Ori becomes useful to more people, great. But the main goal is already being met every time I have fun designing it.

How I created it: the decisions

Nothing here was born ready. The process went roughly like: initial idea, first possibility, unexpected consequence, comparison with alternatives, refinement. Some important decisions and their trade-offs:

Compiler in Rust, native target (AOT). The obvious path would be something interpreted first — faster to prototype. But AOT forces me to carry every feature through codegen, which works as a sanity test for the design: if an idea does not survive native compilation, maybe it was not that good. The cost is iteration speed, and I pay it with open eyes. For quick experiments there is ori run mode, with optional JIT.

Explicit types, no guessing. Aggressive inference saves typing and charges reading: you never know for sure which type is flowing there without asking the tool. Since the proposal is reading-first, explicitness won. It is more verbose — and I prefer honest verbosity over mysterious conciseness.

Readable syntax by default. Any syntactic sugar must justify its existence by proving it does not hurt reading. That rule has already killed several ideas I loved on day one and hated on first re-read. Re-reading, by the way, became method: if I cannot understand my own code a week later without effort, the syntax failed.

Tooling from day one. LSP, clear diagnostics, runnable examples. Documentation and friendly errors take as much work as the compiler — and in a reading-first language, a cryptic error betrays the whole proposal. So good errors are not polish, they are a requirement.

Open specification. Everything — manifesto, spec, planning, changelog — lives in the repository. That is not just transparency: it is what lets agents (and people) work on the project with real context instead of guessing intentions.

Building alongside AI

I need to be honest about one thing: I would not have gotten here alone, and I do not pretend otherwise. AI writes drafts, explores alternatives, points out holes in my reasoning. My job is a different one: deciding. Judging trade-offs, keeping the vision coherent, saying no to good ideas that do not serve this project.

It works because I treat AI as an investigation partner, not an oracle. I ask “what are the alternatives?”, “what breaks if I do it this way?”, “show me where this was tried before.” And I distrust very confident answers — including my own.

There is an interesting side effect: designing a language while assisted by AI taught me a lot about what makes code readable for AIs. Explicit boundaries, documented decisions, small complete examples. Deep down, what helps an agent understand code also helps a person — especially a person with limited working memory, like me.

Current state and next steps

Ori is pre-1.0: the current surface is S3, earlier syntax is rejected, and changes are still allowed before a stable contract. I would rate the project 7/10 today — the foundation (parser, types, codegen, spec) exists and compiles real programs, but better diagnostics, more examples, profiling and validation with real people using it are still missing.

The next step that can confirm or overturn the choices is always the same: compile non-trivial examples, measure, and watch where it hurts. If the pain repeats in the same place, the next decision lives there.

All open in the repository: manifesto, specification, examples and changelog. If you also read more than you write, maybe this language is for you.