Getting Started with EK9

Preface

Most programming books start by warning you about what can go wrong: crashes, values that vanish for no clear reason, the one missing character that breaks a program at three in the morning.

This book starts somewhere else. In EK9, if your program compiles, it is already good.

That is a strong claim, and the first chapter, Hello, EK9, explains why it holds. EK9's compiler is strict on purpose, so a program that builds has already passed the checks that catch whole families of common bugs. Its errors are guidance: each one points at the next thing to fix.

EK9 is a modern language built for large, serious software. It is not a stepping-stone you will throw away later. Along the way the book also teaches the computer science terms and ideas you will meet in any language.

Nothing here is new — and that is the point

Almost nothing in this book is a new idea.

Programmers have known for fifty years that tests catch mistakes early, that data is safer when something controls how it may change, that a value which might be missing ought to say so, and that tangled code is harder to change than tidy code. EK9 did not discover any of this. It was worked out, written down and argued over long before EK9 existed. The original papers are in the footnotes, and some are older than most languages in use today.

What has changed is where the ideas live. In most languages they sit outside the language: testing is a separate tool you add, tidiness is a style guide someone wrote, and review is a step that may or may not happen. They are advice, and advice is the first thing to go when a deadline is close.

EK9 moves the same ideas inside, into the language and the compiler. Testing is part of the language, not a library added afterwards. Controlling what may change your data is a rule, not a convention, whether a type hides its data or forbids other code from altering it. Keeping code loosely connected is a limit the compiler measures.

Two things make the difference. First, the ideas are enforced: the compiler keeps them, so they do not slip when you are busy. Second, they fit together. Instead of separate tools that never speak to one another, testing, controlled state, safe missing values and the quality measures are designed to dovetail, each making the others work better.

So expect not inventions but a great deal of hard-won practice, built into the language and held in place by a compiler that will not let you drift from it. The compiler's error messages and its help also cite the research behind each rule.

Who this book is for

This book is for people who are new to programming, of any age. You do not need to have used another language. You do not need to know what a "null pointer" is, or why experienced programmers wince at "switch fallthrough". Starting fresh is an advantage: you learn good habits without unlearning bad ones.

The ideas here are real, and some are deep. They are not watered down. Each is explained in plain words, one step at a time.

What you need

You need EK9 itself. We recommend the EK9 IDE (started with ek9 -ide), which puts the editor, the compiler and the built-in help in one place, so the compiler's explanation of an error sits next to your code. The Installing and Running EK9 appendix lists the install steps. EK9 also manages its own dependencies, so there is no extra build tooling to set up.

The book shows most commands as they are typed at a command line (a terminal), because a command is exact and the same everywhere. The IDE runs the same compiler.

The IDE also has more advanced tools: an AI assistant, and a link that lets outside AI tools work directly with the compiler. This book does not use them. It teaches the language by hand, so that you understand what those tools do for you.

How to read this book

Work through the chapters in order. Each builds on the ones before it, and the project at the end of the volume uses everything before it.

Every piece of code in this book is a real EK9 program that compiles, and you can run all of them. They are collected in the download, examples.zip, with file names that match the listings in the text.

How code looks

Code appears in boxed listings, like this:

stdout <- Stdout()
stdout.println("Hello, World")

Names of things you type — files, commands, pieces of code — appear in a fixed-width font inside a sentence. The arrows <-, ->, := and so on are EK9 operators. Each is explained when it first appears.

Now and then you will see a boxed note:

Note. A note adds a useful detail or clears up a common mix-up.

Footnotes point to real research.¹ When EK9 leaves something out, it is usually because studies and real-world failures showed that feature caused bugs. If a paper looks hard, read its summary, or ask an AI tool to explain it. Each rule has a reason, and the footnote gives the source.

How this book was made

This book was written by Steve Limb together with Claude, an AI assistant made by Anthropic. Steve created the EK9 language and shaped every chapter; Claude did much of the writing. Every code example was compiled and run against the real EK9 compiler, and every result printed is its actual output. A person and an AI building something together, with the work checked at every step, is the kind of software development EK9 was made for.