Blog › ICP guides

Newsqueak developer on retainer: synchronous rendezvous channels, fan-out patterns, process concurrency, and Newsqueak language on monthly retainer

October 1, 2026 · ~15 min read

A Newsqueak developer was implementing a fan-out communication pattern for a Plan 9 window system event handler. The design created a single event channel and spawned three receiver processes, each reading from the same channel to handle different classes of events. The developer expected that when the sender wrote an event to the channel, all three receivers would get a copy of it — the same broadcast semantics they had seen in message-queue systems with topic subscriptions. The system ran, and the sender wrote events, but only one receiver ever processed each event. The other two receivers blocked indefinitely waiting for events that never arrived. Fan-out mismatches: 3 per message — only one receiver was satisfied per send, leaving the other two waiting. Newsqueak channels are synchronous rendezvous channels: a send operation blocks until exactly one receiver is ready to accept the value, and that receiver gets the value. There is no buffering and no broadcast. The fix required replacing the single shared channel with one channel per receiver, and spawning one dedicated sender process per receiver that forwarded each event from the source onto the appropriate per-receiver channel. After restructuring, each receiver got its own event stream. Mismatches: 3/message → 0 via per-receiver channel redesign.

The work log said “fixed fan-out communication pattern, 5h.” It cannot explain the mechanism: that Newsqueak channels are synchronous rendezvous points rather than queues or broadcast buses, that a send operation is consumed by exactly one receiver regardless of how many processes are waiting on the channel via select, or that replicating a message to N receivers requires N channels and N sender processes rather than N receivers on one channel. A client reading that entry sees five hours for what sounds like a configuration or wiring mistake. What is invisible is the diagnostic cost: verifying that all three receivers were correctly declared and spawned, confirming that the channel type and send syntax were correct, determining that the semantics of Newsqueak channel sends are point-to-point rather than broadcast, and deciding whether the correct restructuring was per-receiver channels with dedicated senders, a multiplexer process that maintained a list of subscriber channels, or a redesign where events were categorized before dispatch rather than broadcast to all receivers.

Newsqueak language overview: synchronous channels and the ancestor of Go

Newsqueak was designed by Rob Pike at Bell Labs around 1989 as a scripting language for the Plan 9 operating system, specifically for writing concurrent event handlers in the Plan 9 window system. Newsqueak was not named for the rodent: the name is a contraction of “new Squeak,” where Squeak was an earlier concurrent scripting language also by Pike. Newsqueak’s design goals were modest in scope but historically influential in impact. The language introduced the specific synchronous rendezvous channel model and select statement that became the foundation for Limbo (the language for the Inferno OS, ~1995) and ultimately for Go’s goroutines and channels (2009). The lineage is direct: Go’s concurrency model is explicitly derived from Newsqueak and Limbo, making Newsqueak the earliest ancestor of one of the most widely used concurrent programming models in production systems today.

Newsqueak programs are collections of sequential processes that communicate through typed channels. The language has a small type system: int, bool, string, and chan T (a channel of values of type T). Functions are first-class values. Variables are declared with := for initialization: c := mk(chan int) creates a new integer channel and binds it to c. Process spawning uses the process{ ... } construct: process{ body statements } launches the body as a new concurrent process, returning to the caller immediately. The spawned process runs concurrently with all other processes. Sending a value to a channel uses the arrow-into-channel syntax: c <- value. Receiving a value uses the arrow-from-channel syntax: <-c as an expression. Both send and receive block: a send blocks until some process is ready to receive, and a receive blocks until some process is ready to send. This blocking behavior is the definition of synchronous rendezvous.

Newsqueak ran on Plan 9 as an interpreter. Programs were scripts that the Plan 9 shell could invoke directly. The primary application domain was window system event handling: a Newsqueak program could read mouse events from a channel, spawn processes to handle keyboard input and window resizes concurrently, and compose event handlers using the select statement to multiplex multiple event streams. This domain shaped the language’s design: the channel model was chosen specifically because it maps event dispatching to channel receives and event handlers to receiving processes.

Synchronous rendezvous channels: sends are point-to-point, not broadcast

The central property of Newsqueak’s channel semantics is synchronous rendezvous: a send and a receive on the same channel must happen simultaneously. Neither can complete without the other being ready. When a process executes c <- value, it blocks until another process executes <-c. When a process executes <-c, it blocks until another process executes c <- value. The value is transferred directly from sender to receiver at the moment of rendezvous. No buffering occurs between sends: if the sender tries to send a second value before the receiver has consumed the first, the sender blocks again.

The critical implication of synchronous rendezvous is that a send to a channel is consumed by exactly one receiver. If three processes are all blocked waiting to receive from the same channel c, and a fourth process sends one value to c, exactly one of the three receivers will unblock and receive the value. The other two remain blocked. The language specification does not define which of the waiting receivers is chosen; in practice Newsqueak selects one, but the developer cannot assume which one. There is no mechanism in Newsqueak to send a single value to multiple receivers simultaneously from one send operation. This is not a limitation of buffering; it is a fundamental property of the channel model. A channel is a meeting point for exactly one sender and one receiver at a time, not a broadcast bus.

This semantics is sometimes confused with message-passing systems that support broadcast or publish-subscribe delivery, where one write to a topic delivers a copy to every subscriber. Newsqueak channels have no such delivery model. Replicating a message to N receivers requires N separate communications, each on a separate channel or via a separate send, each involving a separate sender-receiver pair. The idiomatic Newsqueak approach is: if N processes need to receive every message from a source, create N channels (one per receiver), spawn one dedicated forwarding process per receiver that receives from the source channel and sends to the per-receiver channel, and route the source’s messages by having the source either send to each channel in sequence or hand the work to a dispatcher that manages the forwarding processes.

Process spawning and concurrent composition in Newsqueak

Newsqueak processes are spawned with process{ body }. The body is a sequence of statements. The spawned process runs concurrently, sharing the channel variables that were in scope at the point of the process{} expression — channels are reference types in Newsqueak, and closures over channels are how spawned processes communicate with their spawner and with each other. A typical pattern for creating a producer process is:

source := mk(chan int);
process{
    i := 0;
    for(;;){ source <- i; i = i + 1 }
}
// source now yields an infinite stream of integers

The spawner creates the channel, then spawns a process that continuously sends values to it. The spawner can then receive from the channel using <-source, or pass the channel to other processes that will receive from it. The spawned process runs as long as the program runs, generating values on demand — each send blocks until a receiver is ready, so the generator naturally paces itself to the rate of consumption.

Process termination in Newsqueak happens when the process body reaches its end (or a become statement, described below). There is no explicit process kill or join mechanism. Coordinating process termination requires designing a signaling protocol using channels — a sentinel value on the data channel, or a separate done channel that the process receives from when it should stop. Retainer work frequently involves designing these termination protocols for long-running processes where the client’s mental model is that processes are like threads that can be stopped, rather than sequential bodies that run to completion.

The select statement: non-deterministic choice over multiple channels

Newsqueak’s select statement blocks until one of a set of channel operations can proceed, then executes the corresponding case. The syntax is:

select{
case <-chan1: handleChan1();
case <-chan2: handleChan2();
case <-chan3: handleChan3();
}

If none of the listed channel operations can proceed (no senders are ready on chan1, chan2, or chan3), the select blocks until at least one can. If multiple cases can simultaneously proceed, one is chosen non-deterministically. The selected case is executed, then the select statement completes. To continuously multiplex multiple channels, the select is placed inside a for(;;){} loop.

The non-deterministic choice has a practical implication that retainer work frequently addresses: starvation. If one channel in a select always has a sender ready and another rarely does, the first case will be chosen nearly every iteration, and the second case may never be selected even when its sender is ready. This is not a bug in Newsqueak but a property of non-deterministic selection under asymmetric load. Diagnosing starvation requires measuring the frequency with which each case is selected over a representative run and redesigning either the channel usage patterns or the process structure to ensure liveness of all cases. Work log entry: “diagnosed select starvation under load, redesigned channel usage to ensure all cases receive, 5h” — the hours are justified by the load analysis, the identification of the asymmetric sender-readiness pattern, and the redesign and verification work.

Fan-in and fan-out: the correct channel structures

Fan-in (merging N source channels into one consumer) and fan-out (distributing one source to N consumers) are the two fundamental channel composition patterns in Newsqueak. Fan-in is natural: a process uses select to receive from any of the N source channels and forwards each received value to the single output channel. The select over N inputs automatically interleaves the N streams. Fan-in produces one output value for each input value, so the output rate equals the sum of the N input rates (bounded by the consumer’s receive rate).

Fan-out requires per-receiver channels. The idiomatic structure: given one source channel src and N receiver processes that each need a copy of every value, create N channels r1, r2, ... rN, spawn N forwarding processes process{ for(;;){ rN <- <-src } }, and connect each receiver to its dedicated channel. This structure does not actually give each receiver a copy of every value, however: the N forwarding processes all receive from the same src channel, and each value from src goes to exactly one forwarding process (and thus to exactly one receiver). If the requirement is that every receiver gets every value, the architecture must change: the source must send to N channels explicitly (in sequence), or the source must broadcast through a dispatcher process that maintains the N per-receiver channels and sends to each in a loop. The distinction between “each receiver gets some values” (load balancing) and “each receiver gets every value” (broadcast) determines the correct architecture, and it is the first question to answer in a fan-out retainer engagement.

Typical Newsqueak retainer work and what it looks like in a work log

A Newsqueak retainer typically covers three recurring categories of work. The first is channel semantics debugging: identifying where a developer’s design assumed broadcast, publish-subscribe, or buffered delivery semantics from a synchronous rendezvous channel, and restructuring the channel layout and process topology to implement the intended communication pattern within the synchronous rendezvous model. This work produces no visible feature — it produces a process network that correctly delivers messages. The work log entry “restructured fan-out from single shared channel to per-receiver channels, 3 forwarding processes added, 5h” is auditable: the three new forwarding processes are visible in the code, and the before/after message routing correctness is measurable by counting how many receivers process each event. Without explaining the synchronous rendezvous model and why a single channel cannot broadcast, the entry appears to describe unnecessary complexity.

The second category is select design and liveness analysis. Ensuring that all cases in a select are reachable under realistic load conditions requires profiling the sender rates for each channel, identifying cases where asymmetric rates produce starvation, and redesigning either the channel usage (pacing fast senders) or the process structure (splitting a high-frequency channel into multiple lower-frequency ones to reduce the probability that any one case dominates). This analysis work is invisible in a work log that says “fixed select liveness issue, 5h.”

The third category is process lifecycle design. Newsqueak processes that are spawned as event handlers in Plan 9 window system scripts must be designed to terminate cleanly when the window closes or the script exits. Designing the termination protocol, verifying that processes do not leak when channels close, and ensuring that all blocked processes unblock cleanly at shutdown are retainer tasks that appear as “process lifecycle management, 3h” in a work log and are proportionate when the alternative is a script that hangs at exit because spawned processes are blocked waiting on channels that will never be sent on again.

How HourTab tracks Newsqueak developer retainer hours

Newsqueak retainer work is invisible by the same mechanism that makes channel-based concurrency correct: all state is in the channels and process topology, not in shared variables, so a restructuring that changes message routing produces no visible feature but dramatically changes behavioral correctness. A client who sees “5h — fixed fan-out pattern” cannot assess whether five hours was proportionate to what appears to be adding a few processes and channels. The work log needs to say: the fan-out design used one channel with three receiver processes; Newsqueak channels are synchronous rendezvous — each send is consumed by exactly one receiver; each event went to one receiver, leaving two receivers blocked indefinitely; the fix replaced the shared channel with three per-receiver channels and spawned three forwarding processes, each receiving from the source and forwarding to one per-receiver channel; after restructuring, each receiver got every event; message routing errors: 3/message → 0. That log entry is auditable and justifies the hours by showing the semantic model, the original failure mode, and the structural fix.

HourTab gives Newsqueak developers a public retainer-hours URL they send to clients — typically research groups working on Newsqueak’s historical role in Go’s concurrency model, developers maintaining Plan 9 Newsqueak scripts, academics studying synchronous concurrent languages, and developers porting Newsqueak concurrency patterns to modern languages. For Newsqueak retainers, each work log entry should name the mechanism at the level of the channel model: which channel was shared, what semantics the developer expected vs. the actual rendezvous model, how the topology was restructured, and what the before and after message routing error count is. Comparative context for scope discussions: Newsqueak retainer work has conceptual overlap with retainer work on Limbo (direct successor), Alef (concurrent Plan 9 systems language), and Go (inheritor of the channel model). Senior Newsqueak expertise commands $145 to $260 per hour because the combination of concurrent language semantics depth, Plan 9 window system knowledge, and the historical lineage to Go’s model is extremely rare.

FAQ: Newsqueak developer retainers