Languages, and Where They Run

Circuitry runs eight languages — Python, JavaScript, TypeScript, Go, Rust, C, C++ and Zig — plus Shell when a computer of your own is connected. The choice is made per step, not per document, so one piece of work can wrangle data in Python, hand the heavy pass to Rust, and format the answer in JavaScript.

You pick it in the same place on both surfaces: the language name in a CodeBook cell's toolbar, or the language dropdown on a Code node on the canvas. Those are the same thing — see One document, two views below.

Where each language runs

Compiled languages become WebAssembly

Go, Rust, C, C++ and Zig are not interpreted. The first time you run a step written in one — and again whenever you change its code — Circuitry compiles it to WebAssembly (WASM): a portable, sandboxed machine-code format that runs at close to native speed.

That compile step is what buys you three things at once:

• Speed. A compiled step runs as compiled code, not as a script being read line by line. This is the reason to reach for one — a numeric pass, a parser, an image transform.
• Portability. WebAssembly is not tied to the machine that built it. The built result runs on any device you open the document on afterwards, a phone included.
• Build once. The result is saved with your workflow, so the step runs instantly from then on — with nothing connected, and offline. You are only asked to build again when you actually change the code, and a workflow someone shares with you arrives already built.

Building needs a computer of your own

A compiler is a real program that has to live on a real machine, so this is the one part that cannot happen on the device in your hand:

• In the desktop app — Circuitry Studio for macOS, Windows or Linux — it just works. The first time you run a Go, Rust, C, C++ or Zig step, Circuitry offers to install that language's compiler on your computer, then builds with it. There is nothing to download in advance and nothing to configure; you don't need the language installed already.
• On iPhone, iPad, Android or the web, you need Circuit running on your computer and connected. Circuitry installs the compiler there and builds there, and the result comes back to the device you're holding and runs on it.

Building is part of the Personal plan and above, which is what the desktop app and Circuit come with. Running an already-built step needs neither a plan nor a connection. If a step reports its build tools are missing, run it again to retry.

So the practical rule on a phone or tablet: build once beside your computer, then run anywhere. Nothing about a compiled step ties the finished thing to a desk.

Python, JavaScript and TypeScript need none of this

They run on whatever device you're working on, on every plan, with nothing installed and nothing connected — a phone included. There is no build step and no wait.

• Python also runs natively on a connected computer, which is dramatically faster for real work and is what you want for anything numeric. Choose where a step runs in its settings; a CodeBook picks it up from Show Config.
• TypeScript is written as you would write it in any file — interfaces, annotations, generics. The types come off the moment the step runs, so what executes is your code as JavaScript, in the same place and at the same speed.

Shell is the exception in the other direction: it always runs on a computer of your own, never on the device in your hand.

One document, two views

A CodeBook is a workflow. Not an export of one, not a view generated from one — the same document, the same file, the same run. One engine executes both, so a cell and a node are the same step with the same input, output and settings.

Flip between them whenever you like: Workflow View on the notebook's bottom toolbar takes you to the canvas, and right-clicking a node there offers Open in CodeBook to come back.

Each view is better at a different thing:

• The notebook is linear and familiar. Top to bottom, prose between the steps, results under the cell that produced them. Best when the reasoning matters as much as the answer, and when you'll re-run and re-explain the work.
• The canvas is where a run stops being a straight line. Conditions and switches send it down different paths, loops repeat a section, fork and join split it, parallel processing runs branches at the same time, and with several machines connected each step can run on a different one.

Because it is one document, you don't have to choose once. Narrate an analysis in the notebook, flip to the canvas to fan the slow part out across a cluster of machines, then flip back to write up what it found. When it's finished it is also a workflow you can schedule, call as a webhook or deploy — no rewrite, because there was never a second thing to rewrite.

That is the part a notebook tied to a single language cannot reach: every cell picks its own language, compiled cells run at near-native speed on the device you happen to be holding, and the notebook is a runnable, branching, deployable workflow the whole time.

Related

• Code Node — writing a step in each language: the input/output contract, the standard library, and what a compiled step can't do.
• CodeBook Tour — every control in the notebook, cell by cell.
• Coming from Jupyter — how notebook concepts map across.
• Circuit — the companion app that gives Circuitry your computer.
• Parallel Processing and Several Machines — what the canvas view unlocks.
• Debugging — breakpoints in Python, JavaScript and TypeScript; printing in the compiled five.