This started as a problem with extending an existing OOP application. The domain model didn't fit the problem any longer. A serious refactoring was required. It bothered me.

Why did I write OOP in the first place? Why did I spend so much time migrating CRUD? All that indirection wasn't free. Where did I go wrong?

It is very hard to go up against mainstream ideas. Every textbook is OOP + CRUD, and so every coding agent wants to write OOP + CRUD. But the pointer chasing fights raw performance, and the rigidity of the domain model makes development slow.

After twenty years I've had enough. I committed to Entity-Component-Systems (ECS) and Existence-Based Processing (EBP). This book is the lessons I learned.

The shape is tables and the systems that walk them: data laid out the way the machine reads it, and a new feature added as a column rather than a refactor.

Read online

• GitHub Pages: Introduction - An Introduction to Programming, using ECS & EBP in Rust
• Codeberg: Introduction - An Introduction to Programming, using ECS & EBP in Rust

Source

• GitHub: git clone GitHub - root-11/intro-book · GitHub
• Codeberg: git clone root-11/intro-book - Codeberg.org

Forty-four sections. Every performance claim is backed by a measurement you can run on your own laptop in under a minute. Work in progress. No paywall.

Summary

The book teaches programming from first principles of data-oriented design: entity-component-systems (ECS) and existence-based processing (EBP). Rust is the only language and it assumes no prior programming experience - but it is not a "learn Rust" book. Rust is the vehicle; the subject is laying data out so programs stay fast and stay easy to change as they grow.

The spine is one ecosystem simulator that grows from a hundred wandering creatures to a hundred million streamed ones. Each part moves up one order of magnitude in problem size, and each step forces the next technique - you feel the array-of-structures layout hurt before you are handed structure-of-arrays, you feel the cost of a per-entity conditional before existence-based processing removes it.

Two things set the book apart from most intro material. It is measured, not opinionated: dependencies are priced, not banned (write the from-scratch version, read the crate, then decide), and every performance claim ships with a benchmark you run on your own hardware. There is a cross-machine table - Pi 4, an old i7, a 2015 NUC, a modern Ryzen - so the numbers are yours, not mine. And concepts are named only after they are built: two to three pages of prose, then four to twelve compounding exercises; the vocabulary is earned through working code, never front-loaded.

Is it worth the effort? That was the first question on the Python edition's thread, so let me answer it here, ranked by what actually pays off:

1. Complexity, first and largest. A new feature is an addition, not a restructuring - a new column, or a new presence table plus the system that drives it, bolted on without touching what already works. The cost is front-loaded into learning the structure-of-arrays mindset; after that the marginal cost per feature drops instead of compounding. This is the win I came for, and it is structural rather than a tuning trick.
2. Footprint at scale. Past a million rows, memory is the limit. A structure-of-arrays layout drops the padding an array-of-structures drags through cache; in the book's §7 benchmark the Pi 4 - no L3, a tight memory channel - pays 5.7× for that waste, while a modern desktop with generous L3 mutes it to about 2×. Same principle, slope set by the cache budget.
3. Performance, conditional. It holds as long as your systems stay array-shaped. EBP makes idle behaviour genuinely free: a million-creature world with zero hungry creatures spends zero cycles in the hunger system - work is proportional to active rows, not to population times behaviours, which is one or two orders of magnitude cheaper than a flag-based design for a sparsely active world.

Call for feedback
It is a work in progress (first complete draft). What I would most value from this forum is a close read - where the Rust is non-idiomatic, where a measurement looks wrong on your hardware, where the teaching skips a step.

2 posts - 2 participants

Read full topic