Targets
Each chapter compiles to one target. Programs can still be polyglot.
Each chapter has one compile target, chosen by the Runs as rail:
> Runs as: `go`The target defaults to python. Supported targets:
| Target | Notes |
|---|---|
python | The most mature path. Runs in the artifact venv. |
node | Subprocess execution through a generated adapter. |
ruby | Subprocess execution through a generated adapter. |
go | Docker-backed execution. |
rust | Docker-backed execution. |
typescript | Docker-backed execution. |
bundle | Generic multi-file or native output with a manifest. |
assembly | Strict bundle: real .s source, local clang build, ctypes host adapter. |
Non-Python targets are prototype-grade today and use subprocess, Docker, or generated adapter plumbing. See Limits.
Stack roles
Stack belongs at project level, not repeated in every chapter. A project file declares the stack:
# Project
> Stack: `local_web_app`
> UI: `typescript/react`
> API: `python/fastapi`
> Data: `sqlite`
> Runtime: `docker`Chapter targets can then refer to stack roles or override them:
> Runs as: `stack.api`> Runs as: `ruby`bundle and assembly
bundle is the generic path for multi-file or native outputs. A bundle can
include generated assembly, a generated adapter, and build commands, but the
compiler does not know the app's domain or ABI.
assembly is a stricter bundle target. It requires generated .s source, a
local clang build into a shared library, and a Python host adapter that
calls the native library through ctypes.
One chapter, one target
A composed app can be polyglot because different chapters choose different targets, not because one chapter emits several languages. One chapter generating multiple files is a future design direction, not what the current compiler guarantees.