You write Go. You’ve also watched one bad request take a whole service down with it. Goer borrows Erlang’s best trick for that: split the work into small pieces that can’t touch each other’s stuff, and have a supervisor, whose only job is to watch them, restart the piece that breaks. You keep writing ordinary Go, and use this where it helps.
The idea
Goer gives each piece of work its own little world. When one of those worlds falls over, the rest don’t even notice, and the broken one gets a fresh start.
The name
The name is just Go + Erlang with the join showing. Erlang is the language phone companies built so their switches would stay up for years. Its good ideas are small private processes, something watching over them, and messages instead of shared memory. We wanted those in a place that feels like Go.
You still write Go, and Go stays in charge of your program. Goer is us asking a question out loud: which of Erlang’s ideas are worth having if you already think in Go?
Why Goer
You keep Go’s standard library and everything that makes it practical. What changes is what happens when something goes wrong.
A process is one small worker with an inbox, called its mailbox. It keeps its own notes, reads one message at a time, and nobody else can scribble in those notes. That’s why you can restart it without untangling a web of locks first.
How the model works →When a worker hits something it can’t handle, it stops. A supervisor sees that and starts a fresh one. No try-everything error handling.
You can swap a running process’s code without stopping the system. If its saved data needs a new shape, you write one small function that converts the old shape to the new one.
A process that’s waiting costs almost nothing: a handful of workers share the running, and each process gets its own small box of memory. There’s also a slimmer kind of process for crowds so big that one goroutine each would hurt.
1M processes, measuredThe whole idea in one function
That’s it. A process is a function that takes what it knows and one message, and returns what it knows now. This is the counter from our first tutorial: it adds one per tick, and it crashes on purpose when you ask it to. Press run and it’ll compile right here in the page.
See the first tutorial →type State struct{ Count int }
type Tick struct{}
type Boom struct{}
func Counter(s State, m Msg) State {
switch m.(type) {
case Tick:
s.Count = s.Count + 1
case Boom:
panic("counter asked to crash")
}
return s
}Let it crash
Same counter, told to blow up on every seventh message. The program doesn’t restart. Nothing else stops. And nobody wrote any error handling for it. The supervisor notices, starts a fresh counter, and the ticks just carry on. What you see below is a recording of a real run.
How big can it go?
There are two kinds of process: the regular kind, and a slim kind that only understands a few fixed messages. They share one scheduler (the part that decides who runs next) and one supervisor. Both are measured by a test program in the repo, cmd/megapark, which won’t even start above 100,000 processes unless you pass -n and mean it.
NewSpec/TellSpec), with no memory allocated. The plain Tell is 329 ns. No lock is taken to deliver it.the message-sending benchmarkVMCall/Wide) drops from 623.8 to 141.2 ns, and number-crunching loops run 4 to 8 times faster. Message-passing only gains about 15%, because there the mailbox is the slow part.from our benchmark notesA fair warning about these numbers: they came from a laptop that was busy with other things, so they wobble from run to run. That’s why we compare runs made back to back and report the middle one. On a quiet run the regular kind of process moved 2.23 million messages a second with a 190 ms forced-GC pause (252 ms at worst); after we cut down on garbage it was 2.24 million with 109 ms (144 ms at worst). So the speed didn’t change, and the pause dropped by 40–50%.
Where it runs
Goer runs your process code in an interpreter, which works everywhere. On some platforms it also compiles the busy parts to machine code as the program runs. That’s the JIT (just-in-time) label below. Where there’s no JIT you still get the full thing, just interpreted.
Everything else — macOS, the BSDs, and other CPU types — builds and runs with the interpreter. You don’t pay anything for the compiler not being there.
More than one machine
A node is one running Goer program, and you can connect several. A process’s address works the same whether the process is next door or on another machine. And when a machine drops off, you’re told. Nothing quietly pretends it’s still there.
Ordinary Go programs, connected over the network.
SpawnOn).Down message.You can build Goer as WebAssembly (the wasip1 target) and connect it to other nodes over any plain stream of bytes. Today that’s stdin and stdout.
Attach).Who’s right when two copies disagree?
Most data in Goer has exactly one owner, so there’s nothing to disagree about. For the small amount of data that has to live on several machines at once and still agree later, there’s an optional library.
One process owns each piece of data and handles messages in order.
goer/crdtData that several machines can each change, and that ends up the same everywhere.
FAQ
Short answers. The docs have the long ones.
It’s how a process reaches the outside world. A port is regular Go code that looks like another process: you send it a request, it does the file or network work, and it sends back an answer. The process never opens a file itself. That also makes testing easy, because you can swap in a fake port that just records what it was asked.
The ideas are the same family: small private processes, supervisors that restart them, changing code live, and several machines working together. What’s underneath is different. Goer runs inside a normal Go program. You write the process code in a cut-down version of Go called imgo (files marked //go:build goer), and Goer runs it in its own small virtual machine inside your program.
When what it holds is ordinary Go stuff, like a map of connections or something that needs interfaces. Register it and start it with go Native("name"). Use imgo, our cut-down Go, when you want the stronger promises: nothing can reach in, the code can be changed live, and the only way out is through a port (Go code the process sends requests to). Both kinds run side by side and can message each other.
A process switches to the new code between two messages, never in the middle of one. Messages already waiting stay in line. If the data’s shape changed, your conversion function runs once at that moment. HotSwap changes the running process; Migrate also changes what a later restart will use.
Any function in a process’s code that’s been called 1,000 times. (That code is written in imgo, our cut-down Go.) It helps most with loops and number work. If a function can’t be compiled it just keeps running in the interpreter, and the two are tested against each other to give identical results.
Because the compiler produces amd64 or arm64 machine code, and WebAssembly is neither. WebAssembly sets that limit. The whole runtime still runs there, and it’s a full member of the cluster.
Every process watching something on that machine gets a Down message. A supervisor treats it like a crash and uses up one restart. So a dead machine can’t leave a process missing without anyone knowing.
No. The tutorials explain each idea in plain words and Go code. Nothing assumes you’ve seen Erlang.
In its own block of memory inside your Go program. When the process ends, the whole block is handed back. That memory goes away when the program stops, so saving things to disk is up to you. If you need data to survive across machines, that’s what goer/crdt, our library for shared data, is for.
Read the docs
Get something running first. Then find out why it’s built this way, keep the reference handy while you build, and learn to watch a live system.