2026.10.10beanstalkd-rs: A Drop-in beanstalkd in Rust, with a Raft Cluster14 min read Operations per second, beanstalkd vs beanstalkd-rs Horizontal bar chart, higher is better. put-reserve-delete, 1 connection: beanstalkd 56,176, beanstalkd-rs 53,943 (0.96×); put-reserve-delete, 10 connections: beanstalkd 339,283, beanstalkd-rs 468,310 (1.38×); put-reserve-delete, 100 connections: beanstalkd 392,713, beanstalkd-rs 516,336 (1.31×); 100 connections, 4 KiB bodies: beanstalkd 362,247, beanstalkd-rs 463,416 (1.28×); 100 connections, 16 pipelined: beanstalkd 490,247, beanstalkd-rs 643,204 (1.31×); producers and consumers, 100 connections: beanstalkd 422,349, beanstalkd-rs 500,891 (1.19×); binlog (-b), 100 connections: beanstalkd 267,391, beanstalkd-rs 594,148 (2.22×). Operations per second (higher is better) 0.96× 1.38× 1.31× 1.28× 1.31× 1.19× 2.22× beanstalkd beanstalkd-rs beanstalkd-rs / beanstalkd 0 100k 200k 300k 400k 500k 600k 700k put-reserve-delete, 1 connection put-reserve-delete, 10 connections put-reserve-delete, 100 connections 100 connections, 4 KiB bodies 100 connections, 16 pipelined producers and consumers, 100 connections binlog (-b), 100 connections 56k 54k 339k 468k 393k 516k 362k 463k 490k 643k 422k 501k 267k 594k
2026.08.22The Agent Runtime Problem: Four Things a while-Loop Doesn't Give You15 min read What a runtime owns that a framework does not Four quadrants, each naming a problem an agent runtime has to own. One, durable state: a crash between the tool and the push, answered by two commits around one uncertain call. Two, session ownership: the terminal dies with the agent, answered by a daemon that reports working or blocked. Three, the orchestration loop: the author reviews its own diff, answered by splitting the context window rather than the model. Four, identity and money: no name to present and no way to pay, answered by HTTP 402 plus a delegation boundary. The four are independent, and no project has all four. What a runtime owns that a framework does not four independent problems — no project on this list has all four 1. durable state crash between the tool and the push→ two commits per uncertain effect 2. session ownership the terminal dies with the agent→ a daemon that owns the session 3. the orchestration loop the author reviews its own diff→ split the context, not the model 4. identity and money no name to present, no way to pay→ HTTP 402 plus a delegation boundary a framework gives you a while-loop and tool plumbing a runtime owns what survives the process
2026.08.20gpui and the Mail Client Problem: A Text Field Costs 778 Lines28 min read The same event, two boundaries Two columns on a shared five-row grid, tracing the same event — a message landing in the mailbox while the user scrolls the thread list. Left column, Tauri or Electron: a sync task in the Rust core owns the store and the socket; the envelope is serialised to JSON, which is the only wire format the event system offers; the payload crosses into the WebView as evaluated JavaScript; a listener rebuilds the row, producing a second copy of the same data on the JavaScript heap; and a virtual list finally writes it into the DOM of WebView2, WKWebView or WebKitGTK depending on the user's operating system. Right column, gpui: the sync task runs on the background executor inside the same crate and the same address space; cx.spawn hops back to the main thread with an AsyncApp held across the await; store.update leases the state out, mutates it and returns it; cx.notify queues an effect that is flushed after the update completes; and the uniform list paints only the visible range on the next GPU frame. The left path buys a serialiser and a runtime you do not own, but gets a text field, a table and accessibility for free. The right path is a function call, and a design system you now maintain yourself. The same event, two boundaries a message lands in the mailbox while the user is scrolling the thread list Tauri / Electron sync task, Rust core owns the store and the socket serialise the envelope JSON — the only wire formatevents "are always JSON strings" cross into the WebView payload arrives as evaluated JS listener rebuilds the row a second copy on the JS heap virtual list, then DOM WebView2 / WKWebView / WebKitGTK gpui sync task, background executor same crate, same address space cx.spawn back to the main thread AsyncApp held across the await store.update(cx, ..) state leased out, mutated, returned cx.notify() effect queued, flushed after update uniform_list, next frame visible range only, painted by the GPU left: a serialiser, and a runtime you do not own right: a function call, and a design system you now maintain the left column ships a text field today; the right one charges 778 lines
2026.08.17X's Phoenix Ranker: A Transformer That Cannot See Its Own Batch33 min read One sequence, three regions Three stacked bands, one per region of the Phoenix ranking model's input sequence. First, the user prefix at positions 0 to 1: two hashed identifier lookups and two hashed IP lookups, plus country, language, latitude and longitude, gender, age and installed apps; it attends to the user prefix and the history. Second, the history at positions 2 to 1023: post hashes, author hashes, semantic ID, the action taken, dwell time, timezone, local hour, product surface and post age; it attends to the user prefix and the history, bidirectionally rather than causally. Third, the candidates at positions 1024 to 1087: post hashes, author hashes, semantic ID and context, but no action and no dwell, because those are what the model predicts; a candidate attends to the user prefix, the history and itself, and nothing else. Right-anchored rotary position embedding puts the newest history event at position 1023 whatever the history length, and every candidate receives position 1024. A candidate's score therefore depends on the viewer and that candidate only, never on which other candidates share its batch. One sequence, three regions the Phoenix ranker reads 1088 positions in a single non-causal pass user — positions 0…1 two hashed id lookups, two hashed IP lookupscountry · language · lat/lon · gender · age · installed appsattends to: user + history history — positions 2…1023 post hashes · author hashes · semantic ID · action takendwell time · timezone · local hour · surface · post ageattends to: user + history — bidirectional, not causal candidates — positions 1024…1087 post hashes · author hashes · semantic ID · contextno action, no dwell — those are what the model predictsattends to: user + history + itself, and nothing else right-anchored RoPE puts the newest history event at 1023 whatever the history length every candidate gets position 1024 a candidate score depends on the viewer and that candidate alone never on which candidates share its batch
2026.08.07Bun's Zig→Rust Rewrite in 11 Days: The Loop, Not the 64 Claudes23 min read Bun’s port loop: split the context window A four-stage loop running top to bottom. At the top, the binding spec: PORTING.md and LIFETIMES.tsv, holding the Zig-to-Rust pattern rules and a proposed lifetime for every struct field in the codebase. It binds all four stages below it. Next, one implementer, which sees the Zig source, the spec, and its own reasoning, and writes the port. Its diff — and nothing else — goes to two adversarial reviewers, each instructed to assume the code is wrong; neither sees the implementer's reasoning. Their findings go to one fixer, which applies every finding before the code lands. Sixteen such loops ran per git worktree across four worktrees, roughly sixty-four Claude instances at peak, and the same loop shape drove all three phases: translating 1,448 files, clearing about 16,000 compiler errors, and fixing every failing test. Bun’s port loop: split the context window the reviewer gets the diff and nothing else — never the implementer’s reasoning binds all four diff only findings PORTING.md + LIFETIMES.tsv the binding spec · Zig→Rust patterns, a lifetime per struct field 1 implementer sees the Zig source, the spec, and its own reasoning adversarial reviewer adversarial reviewer 1 fixer applies every finding — only then does the code land sees the diff only · instructed to assume the code is wrong 16 loops per worktree · 4 git worktrees · ~64 Claudes at peak the same loop drove all three phases: translation, compiler errors, failing tests
2026.08.07herdr Joins Y Combinator: A Rust Agent Runtime, Not Another tmux14 min read herdr: the agent runtime Three layers. On top, clients: Claude Code, Codex, opencode and a human. Each attaches to the herdr daemon. The daemon owns every terminal session, persists agent state, and is reachable from anywhere through the bundled TUI (herdr --remote self-installs in seconds). Below, the sessions it spawns, one per agent, marked working, blocked or idle, each surviving agent restarts. A terminal pane belongs to an agent; a pane belongs to a tab; tabs belong to a project. herdr: the agent runtime agents attach to a daemon that owns every session and tracks its state attach spawns · owns Claude Code Codex opencode Human herdr daemon owns every session · persists agent state terminal session terminal session terminal session working blocked idle state detected per pane · sessions survive agent restart a terminal pane belongs to an agent · a pane belongs to a tab tabs belong to a project · run them anywhere, keep them running herdr --remote self-installs in seconds
