Playground / in the browser

Run a process without installing anything.

Curious, but not ready to install anything? Fair enough. A process is one small worker with its own data and its own inbox of messages, and here you can run one. This page has the real Goer in it, built as WebAssembly so it can run in a browser (a few megabytes). Change the program below, press Run, and it’s compiled and run right here in the tab. It starts as the counter from the first tutorial. Run it once, then start breaking it.

Words this page uses

process: One small worker inside your program. It keeps its own private data, reads one message at a time from its own inbox, and can be restarted without disturbing anything else. Some people call it an actor.
imgo: The cut-down version of Go that processes are written in. An imgo file is a Go file with //go:build goer as its first line; Goer compiles it and the normal Go compiler skips it.
behaviour: The function that handles a process’s messages. It takes the state and one message, and returns the new state.
state: The data one process keeps. Only that process can read or change it.
supervisor: The part of Goer that watches processes. When one crashes, the supervisor is told and decides whether to start a fresh one.
mailbox: A process’s inbox: the line of messages waiting for it.
port: Ordinary Go code that a process can message to reach the outside world: files, networks, clocks, other services. A process can’t touch those directly.
node: One running Goer program. Each node has a name.
WebAssembly: A portable program format that runs in browsers and other sandboxes. Often shortened to wasm.

Every word, in one place →

loading the runtime…

What happens when you press Run

The playground looks for one behaviour function: a function that takes the state and a message and returns the new state, like func Handle(s State, m Msg) State. It also needs a matching HandleInit() State for the starting state. If your program has several functions shaped like that, name the one you want run Handle.

Then it does the same thing every time. It sends your process each kind of message your behaviour handles, once each, in the order you declared them, with every field set to zero. After each one it prints what the state looks like now.

If a handler panics, the process crashes, the supervisor starts it again from HandleInit, and you see both the reason and the fresh state. If a handler loops forever, Goer cuts it off after a set amount of work and that shows up as a crash too. A real system does exactly the same.

Things to try: make Tick add two. Panic on something else. Add type Reset struct{ N int } and a case for it. The playground picks up new message types on its own.

What a playground program can’t do

The playground has no outside world to talk to. So anything that needs one is out:

No ports

Port("fs") has nothing behind it here, so asking a port for something fails and crashes the process. That’s the honest result: files and networks live outside process code.

Timers don’t get waited for

After and SelTimeout use the real clock, and the playground reads the state straight after each message. Leave timeouts out of your experiments here.

No other machines

There’s one node and nobody to connect to, so Remote(...) can’t deliver. Starting local children with Spawn(Worker) works fine.

One file

You can’t import other packages, only goer’s builtins. For anything bigger, goer run on your own machine is the place.

Everything else is real.The errors are the real compiler’s errors. The process is a real process with real memory and a real mailbox. The crash and the restart are the real supervisor’s. The only thing missing is the world outside.

Getting startedRun the same counter on your machine →The imgo languageWhat it allows and what it refuses →Debugging live systemsPause, step, and look inside a real one →