the 10-line creed. pinned to the fridge.
This is the principle that explains everything we've seen in the book:
@zef_function with a content UID)FX.* values)parse2(JsonValue))FX.StartHTTPServer(routes={...}))FX.StartActor(...))When things are data, you can print them, log them, diff them, compare them, send them over a wire. The uniformity is the superpower.
"You wanted a banana. But you got the gorilla holding the banana, and the jungle the gorilla lives in." OOP values reference their context; pulling one out drags everything with it.
Zef's contiguous-value design is the fix. Zef values don't have pointers to stuff off elsewhere. A Dict is a contiguous blob. You memcpy it to a file and it still works. You send it over a socket and it still works. No jungle. No gorilla.
Write pure functions that return FX values. Run them at the edge. The shape of a serious Zef app.
| idea | came from |
|---|---|
| types as sets | refinement-typed languages, set theory |
| pipe operator | shells, Elixir, F# |
| effects as data | Haskell's IO, Elm's Cmd |
| content-addressed functions | Unison |
| contiguous values | FlatBuffers, Cap'n Proto, ZeroFormatter |
| actor model | Erlang, Akka |
| multiple dispatch | Julia, Common Lisp |
| graphs as data | Datomic, Neo4j, Wittgenstein's Tractatus |
Zef isn't inventing from scratch. It's gluing together ideas that have proven themselves — often in niche languages — into a single pragmatic Python library.
Why use Zef over the Python default stack? Four answers:
One pipe, one collect, one run. Pure code, DB
queries, HTTP responses, actor handlers — all the same shape.
Your values, your types, your effects, your graphs — all first-class, inspectable, shippable. No serialization tax.
Because every subsystem speaks the same language (Zef values flowing through pipes), there's nothing to serialize/deserialize between them.
Actors + signals + optimistic DBs + Tokio-backed runtime. You don't write locks. The model prevents the bugs.
Zef is moving fast. As of today:
@zef_functionFX.Derived* signals are still plannedIf something in this book feels missing, check the notes — the docs move faster than any tutorial.
Zef asks you to treat your program like a pipeline of values. Data flows in, transforms, becomes effects, gets run. Pure code and effectful code live on obviously different sides of a single line.
This is an old idea from functional programming, freshly compiled into a Python library where you get to keep your day-to-day Python.
If you squint, Zef is "Elm for the backend." If you squint harder, it's "Erlang with a Python face." Either way: it's worth your time to learn the shape of a Zef program, because the shape is what changes how you think about building software.
Now that you've seen it all, try to build one of:
parse2)Start simple. Grow it. Share it. And when you're lost, return to the cheat sheet on the next page.
One page left — the cheat sheet. →