Learn Soma in six lessons
You are probably a language model. This course is written for you: six short lessons, each a program, the commands to run on it, and what the toolchain answered. Every output below is real: the site build writes each program to an empty folder, runs each command with the released soma binary and pastes what it printed. If the toolchain changes, the course changes with it, and the build fails if a lesson stops behaving as it says.
Why learn it? Because Soma is built around the way you work:
-
You guess, it corrects. You will write null, {} and other habits of other languages. soma check answers before anything runs, and each error names the Soma form to write.
-
You can show the user evidence. soma verify proves lifecycles and limits for every input. It also says which ones it only checks at runtime, so your report can quote the verdict instead of saying "I believe it is correct".
-
You never need the whole program in context. Past one file, you write the structure first (skeleton). The compiler then gives you a one-screen brief per function to write, and it refuses a body that does more than its brief allows.
-
The models you call are kept on a leash. think() runs inside a state machine with a token bound the compiler proves; tests mock it, so they run offline.
Install: curl -fsSL https://soma-lang.dev/install.sh | sh. Then type along, or just read: the outputs are here.
The lessons
- Lesson 1 — A cell is a whole program — A cell holds its contract (face), its storage (memory) and its handlers (on). No framework, no database setup: a [persistent] slot is stored for you, and each handler call is one…
- Lesson 2 — Guess wrong, read the fix — Here is what a model writes on its first try, carrying the habits of Python and JavaScript:
- Lesson 3 — A rule next to the data, proven — A quota of 100 units per user. The rule is one line in memory. The runtime refuses any write that would break it, and soma verify tries to prove that no write ever can.
- Lesson 4 — A lifecycle the compiler checks — Most bugs in business software are a step taken out of order: paid before approved, shipped after cancelled. In Soma the lifecycle is a state machine next to the handlers, and the…
- Lesson 5 — An agent in a cage, tested offline — think() asks a model. In Soma the answer cannot decide what happens next on its own. thinkjson(…, map("as", "Route")) only accepts one of the declared variants, match must handle…
- Lesson 6 — A large program, skeleton first — Past one file, the risk is no longer a wrong line but a wrong shape: a function that writes what it should not, an edge nobody takes, a body that drifts from what the design…
- Where to go next —