DEV Community: stepinto.dev

Learning the Heater From Its Own Logs

stepinto.dev — Fri, 16 Oct 2026 19:44:40 +0000

The first code post in this series had a predict function whose body I typed by hand. Heat leaks towards outside at a tenth of the difference per step, the heater adds a degree and a half, and I made both of those numbers up. That was fine for showing the shape of a world model. It is useless for a real room, because a real room does not tell you its constants. What it gives you instead is a log.

This post throws the hand-written body away and fits a new one from logged state and action pairs. The model is four numbers. The training loop is twenty lines. At the end it predicts a room it has never seen more closely than my guess did, and you can run the whole thing in your browser.

A room that keeps its constants to itself

I don't have a thermostat wired up to this blog, so a simulator stands in for the hardware. It has the same shape as the 101 predict, with two changes: the constants are different from the ones I guessed, and there is a little noise, because someone keeps opening the door.

const REAL_LEAK = 0.07;   // better insulated than I guessed
const REAL_HEAT = 1.2;    // and a weaker heater
const NOISE = 0.1;        // draughts, in °C per step

function realRoom(state: State, action: Action): State {
  const heaterOn =
    action === "turnHeaterOn" ? true :
    action === "turnHeaterOff" ? false :
    state.heaterOn;
  const leak = (state.outsideTemp - state.roomTemp) * REAL_LEAK;
  const heat = heaterOn ? REAL_HEAT : 0;
  const draught = gauss() * NOISE;
  return {
    roomTemp: state.roomTemp + leak + heat + draught,
    outsideTemp: state.outsideTemp,
    heaterOn,
  };
}

The rule for the rest of the post is that nothing below this line gets to look inside realRoom. The model only sees what a logger would see.

Recording the logs

The log comes from running a thermostat against the room. Each episode picks an outside temperature between 2 and 12 degrees, a starting room temperature between 10 and 22, a setpoint between 18 and 21, and runs sixty steps. One step in five the thermostat does something random instead, because a log with only sensible decisions in it never shows the model what a daft decision does. Eighty episodes gives 4,800 transitions, each one the Transition type from the 101 post.

function record(episodes: number, steps: number): Transition[] {
  const log: Transition[] = [];
  for (let e = 0; e < episodes; e++) {
    let state: State = {
      roomTemp: 10 + rand() * 12,
      outsideTemp: 2 + rand() * 10,
      heaterOn: rand() < 0.5,
    };
    const setpoint = 18 + rand() * 3;
    for (let t = 0; t < steps; t++) {
      const action = thermostat(state, setpoint);
      const nextState = realRoom(state, action);
      log.push({ state, action, nextState });
      state = nextState;
    }
  }
  return log;
}

const log = record(80, 60);

Here are the first two rows, which is all of the data the model ever gets, four thousand eight hundred times over.

{ state: { roomTemp: 16.51, outsideTemp: 7.62, heaterOn: false },
  action: "turnHeaterOn",
  nextState: { roomTemp: 17.09, outsideTemp: 7.62, heaterOn: true } }
{ state: { roomTemp: 17.09, outsideTemp: 7.62, heaterOn: true },
  action: "wait",
  nextState: { roomTemp: 17.75, outsideTemp: 7.62, heaterOn: true } }

If you run energy hardware, this is your telemetry table with the commands joined on, which was the whole point of the first post.

The WHERE clause runs out

The last post computed a world model with a filter and a count: keep the rows where the state and action matched, tally what happened next. It worked because temperatures were bucketed into cold, mild and warm. Try it on the real log and it falls over immediately.

const probe = log[1234];
const matches = log.filter(t =>
  t.state.roomTemp === probe.state.roomTemp &&
  t.state.outsideTemp === probe.state.outsideTemp &&
  t.state.heaterOn === probe.state.heaterOn &&
  t.action === probe.action);

matches.length;  // 1, and it's row 1234 itself

Loosening the match to within a twentieth of a degree finds two rows. A continuous state almost never recurs, so the condition on the right of the bar almost never matches, which is the same wall the LLM equation hit in that post. The fix there was a very large neural network. The fix here is a very small one, because the room is a very small world.

The model is four numbers

What I want is a function with the predict signature whose body I did not write. The simplest body that could work is a weighted sum. Take the readings the logger can see, multiply each by a weight, add them up, and call the result the change in room temperature for this step.

type Weights = { room: number; outside: number; heater: number; bias: number };

function features(state: State, action: Action) {
  const heaterOn =
    action === "turnHeaterOn" ? true :
    action === "turnHeaterOff" ? false :
    state.heaterOn;
  return { room: state.roomTemp, outside: state.outsideTemp, heater: heaterOn ? 1 : 0, bias: 1, heaterOn };
}

function predictWith(w: Weights, state: State, action: Action): State {
  const f = features(state, action);
  const delta = w.room * f.room + w.outside * f.outside + w.heater * f.heater + w.bias * f.bias;
  return { roomTemp: state.roomTemp + delta, outsideTemp: state.outsideTemp, heaterOn: f.heaterOn };
}

Predicting the change rather than the next temperature outright is the one design decision in here, and it matters more than it looks. The next temperature is dominated by the current temperature, so a model asked to predict it spends its capacity learning "next is roughly the same as now" and has little left for the interesting part. The change is the interesting part on its own.

Notice what the model is not given. It does not know that the leak depends on the difference between inside and outside. It gets the two temperatures as separate inputs and has to discover the relationship, if there is one.

The training loop

Training means finding the four weights that make predictWith agree with the log. Gradient descent does that the slow and honest way: start at zero, measure how wrong the model is across every row, nudge each weight in the direction that reduces the error, repeat.

function train(log: Transition[], epochs: number, lr: number) {
  const w: Weights = { room: 0, outside: 0, heater: 0, bias: 0 };
  const losses: number[] = [];
  for (let epoch = 0; epoch < epochs; epoch++) {
    const g: Weights = { room: 0, outside: 0, heater: 0, bias: 0 };
    let loss = 0;
    for (const t of log) {
      const f = features(t.state, t.action);
      const target = t.nextState.roomTemp - t.state.roomTemp;
      const guess = w.room * f.room + w.outside * f.outside + w.heater * f.heater + w.bias * f.bias;
      const err = guess - target;
      loss += err * err;
      g.room += err * f.room; g.outside += err * f.outside;
      g.heater += err * f.heater; g.bias += err * f.bias;
    }
    const n = log.length;
    w.room -= lr * g.room / n; w.outside -= lr * g.outside / n;
    w.heater -= lr * g.heater / n; w.bias -= lr * g.bias / n;
    losses.push(loss / n);
  }
  return { w, losses };
}

const { w, losses } = train(log, 10000, 0.003);

The err * f.room lines are the entire derivative. For a weighted sum with a squared error, the gradient of the loss with respect to each weight is the error times that weight's input, which is why no library is needed. Ten thousand passes over 4,800 rows takes about 300 milliseconds in Node 23.

{{< chart name="heater-loss" csv="heater-loss" caption="Mean squared error per epoch. It flattens at 0.01, which is the variance of the draughts: the model has learned everything in the log that is not noise." >}}

Ten thousand epochs is a lot for four weights, and the reason is worth knowing. Room temperature and outside temperature move together in the log (warm days make warm rooms), so the loss surface is a long thin valley and plain gradient descent zigzags down it. Scaling the inputs or using a smarter optimiser would fix that in a few hundred epochs. I left it slow because the loop is easier to read this way, and because the playground is more fun when you can watch it converge.

Here are the weights it found, next to the constants realRoom was hiding.

weight	learned	truth
room	-0.074	-0.07
outside	0.069	0.07
heater	1.19	1.2
bias	0.077	0

The room and outside weights came out equal and opposite. Nobody told the model that heat flow depends on the difference between the two temperatures. It found that from the logs, which is the small version of the thing world models are for. The bias absorbed a little of the room weight's share, because the two inputs are correlated and the noise lets them trade off. That is what a fit looks like when the data is real rather than typed in.

And predict now has a learned body with the same signature as before.

const predict = (state: State, action: Action) => predictWith(w, state, action);

A room it has never seen

The test that matters is a room outside the training range. Every episode in the log had an outside temperature between 2 and 12 degrees. The test room is at minus four, starts at 22, and follows a script the thermostat never produced: heater off for ten steps, on for ten, off for ten. The same script runs through three functions: the real room, the learned model, and the hand-written guess from 101.

const unseen: State = { roomTemp: 22, outsideTemp: -4, heaterOn: false };

// rollout from 101, with the step function passed in instead of baked in
const truth = rollout(unseen, script, realRoom);
const learned = rollout(unseen, script, predict);
const guessed = rollout(unseen, script, predictGuess);

{{< chart name="heater-rollout" csv="heater-rollout" caption="Thirty steps at minus four outside. The learned model tracks the real room to within a few tenths of a degree the whole way. The hand-written guess leaks too fast and heats too hard, and is three degrees adrift by step thirty." >}}

The numbers at the three turning points:

step	real room	learned	hand-written
10, heater goes on	8.78	8.79	5.07
20, heater goes off	11.02	11.28	8.93
30	3.69	3.80	0.51

Root mean square error over the thirty steps is 0.20 degrees for the learned model and 2.77 for my guess. The model extrapolated to an outside temperature six degrees colder than anything in its logs, because what it learned was the physics rather than the trajectories. A lookup table could not have done that, and neither could I, since I had the constants wrong.

What four weights cannot hold

The playground at /heater/ runs all of the above. Change the room's constants, record fresh logs, press train, and watch the weights settle while the prediction on the right pulls into line with the real room. Turn the draughts up and the loss floor rises to match. Set the leak rate to 0.10 and the heater to 1.5 and the hand-written guess becomes correct, which is a nice reminder that my guess was only ever a model with its weights typed in.

It also shows where this model stops. The weighted sum can only learn relationships that are a straight line through the inputs it can see. The room I built is linear and fully observed, so four weights are enough. Give the real room a door that opens and closes on a schedule the logger never records, and the best a linear model can do is average over the door, predicting a room that is always half open. The field it needs is one that is not in the log. The 102 post called that a private field, and the next post gives the model one and watches it work out the door on its own.

A Partial JSON Parser You Can npm install

stepinto.dev — Fri, 16 Oct 2026 14:56:44 +0000

Two years ago I wrote a partial JSON parser for one job: pulling the response field out of a half-received LLM reply so the text could appear on screen while the rest of the JSON was still streaming. The post ended with a ninety-line function in a code block and a gist to copy. The streaming post that followed it leaned on the same function, and each app I used it in got its own copy with the field name changed, which is the sign that a code block should have been a package.

So it is one now.

npm install fenced-json

It has no dependencies, runs in Node and the browser, ships with tests, and there is a playground where you can paste a response, replay it a few characters at a time, and watch the fields appear. This post is about what had to change when the function stopped being specific to my app.

What the old one did

The 2024 version made four assumptions, and said so:

I only care about one field (response). The structure is known and flat. The value I need is always a string. I'm already handling the stream myself.

Given those, the implementation was indexOf('"response"'), skip to the opening quote, then walk characters handling escapes until the closing quote or the end of the text. The post described it as "scrappy, specific to my use case" and it was. It also listed what it did not handle: nested objects, arrays as the streaming target, unknown schemas, non-string values.

A general version has to drop every one of those assumptions, and each one turned out to hide a design decision rather than just more code.

Where does the JSON start

The first problem is not JSON at all. Models wrap structured output in a markdown fence because the system prompt told them to, and some models add a line of prose first ("Sure, here is the structured answer:") no matter what the prompt says. The old code searched for

```json

and chopped. That works until the fence has not fully arrived.

Consider the text so far being Sure!\n`json. Is the JSON about to start? Probably. But the parser cannot tell the language tag from the start of the content until the newline arrives, so the honest answer is "nothing yet". The same goes for Sure!\n on its own: a fence may be coming, or bare JSON may be coming, or the model may be about to ramble. The package returns a state of empty for all of these and parses nothing.

Once there is a fence followed by a newline, parsing starts after it. When there is no fence, parsing starts at the first { or [. That second rule is a compromise: a brace inside the preamble would trip it. In practice preamble before bare JSON is rare, because models that add preamble tend to also add fences, and you can turn the rule off with fences: false if you know the text is bare JSON and want a preamble to be an error.

After the closing brace, whatever follows (the closing fence, a "Let me know if you need anything else") goes into rest, so you can show it or drop it.

A half string is a string, a half number is a lie

The old parser only streamed strings, and a prefix of a string is useful: "Here's what I fou" is readable and the user sees it grow. Generalising to every JSON type forced the question of what a prefix of each type means.

Cut inside a	What you get	Why
string	the prefix so far	a partial sentence is still readable
escape sequence	the string without the half escape	`\u00` is not a character yet
number	nothing, until a delimiter arrives	`12` may be about to become `125`
`true`, `false`, `null`	the completed literal	only one literal starts with each letter
object key	nothing, the key is left out	a key with no value is not a field
array or object	the container, closed	with whatever children have arrived

The number rule is the one I went back and forth on. Every other partial-JSON library I tried returns 12 for {"n": 12 at the end of the text, and for a price field that is wrong by a factor of ten for the duration of one chunk. A string prefix is a true statement about the final string. A number prefix is not a true statement about the final number. So the default drops it, and partialNumbers: 'keep' brings it back for the cases where a flickering digit is acceptable.

Strings get the opposite treatment with the same reasoning in reverse. The default keeps the prefix because that is the whole point for display text. But if the string is an enum or an identifier you will switch on, a prefix is dangerous: "lang": "e" is not "en". For those, partialStrings: 'drop' holds every string back until its closing quote. It is a per-call option rather than per-field because the parser does not know your schema; you can call it twice with different options if you need both behaviours, and at the sizes involved that costs nothing.

Which field is streaming

With one field there was no question of which field was still arriving. With a whole tree there is, and it matters more than I expected. The suggestions list in my own app should render once it is complete, not item by item with half a name on the last one. The response text should render as it grows. Both come from the same parse result, so the result has to say where the cut is.

The parser tracks its path as it descends and records it the first time it runs out of text. For {"a": "x", "b": [1, {"c": "d the streaming path is ["b", 1, "c"]. For {"a": "x", "b": [1, {"c it is ["b", 1], because the inner object is open and its next key is incomplete. When the document is complete the path is null.

From that path, isComplete(result, ["b", 0]) is a one-line check: the value at the path exists, and the streaming path does not pass through it. A field that has not arrived yet is not complete either, which is the case the obvious implementation gets wrong.

`ts const r = parsePartial('{"response": "done", "items": [{"id": 1}, {"id": 2, "name": "Lu'); r.streaming // ['items', 1, 'name'] isComplete(r, ['response']) // true isComplete(r, ['items', 0]) // true isComplete(r, ['items', 1]) // false isComplete(r, ['language']) // false, not arrived `

Incomplete is not invalid

The old function returned null for "nothing to show yet" and there was no way to say "this will never parse". Models do emit broken JSON occasionally: a trailing comma, a single-quoted key, an unescaped quote. A general parser has to distinguish "not yet" from "never", because the UI response differs. For "not yet" you wait. For "never" you stop waiting and fall back to showing the raw text.

The result's state is one of empty, partial, complete or invalid, and the rule the tests enforce is that every prefix of a valid document is one of the first three. The test suite takes a sample document and parses all of its prefixes, asserting that none is invalid and that every value returned is a sub-tree of the final value (every string a prefix of the final string, every array no longer than the final array, every key present in the final object). That one property test is also what settled the partial-number rule. I had written the obvious expectation, that [1, 2 parses to [1, 2], and the test failed because the trailing 2 had been dropped. Writing out why the drop was right is where the table above came from. The escape-sequence cases, \u split across two chunks among them, are the ones the 2024 version would have got wrong, so they each have their own test.

invalid carries the offset where parsing failed, which turns out to be useful for prompt debugging. If the model keeps producing bad JSON at the same offset, you learn something about your schema.

Re-parse, do not be clever

The obvious architecture for a streaming parser is incremental: keep the state machine between chunks and only consume new characters. The Vercel AI SDK's fixJson is a single-pass scanner of that sort. I started down that road and stopped, because the incremental version needs the partially built tree to be mutable in place, and then the value you handed the caller last chunk changes under them. Immutable results mean a fresh tree each time, and a fresh tree means you may as well re-parse.

Re-parsing from the start on every chunk is quadratic in the response length. For LLM responses that does not matter, and I measured rather than asserted it. The benchmark feeds a pretty-printed fenced document in twenty-character chunks and times the whole stream, taking the best of several runs.

Document	Chunks	Total	Per chunk
1 KB	61	0.2 ms	3 µs
4 KB	215	2.3 ms	11 µs
16 KB	826	33 ms	40 µs
64 KB	3,286	523 ms	159 µs

Node 23.11 on an M-series laptop. A typical chat response with a few suggestions attached is under 4 KB. Even at 64 KB the per-chunk cost is well under a frame. If your structured output runs to hundreds of kilobytes, you want an incremental parser and this is not it, and the README says so.

The API

Three exports do the work.

`ts
import { parsePartial, PartialJson, isComplete } from 'fenced-json';

type Reply = {
response: string;
language: string;
items: { id: string; name: string }[];
};

const json = new PartialJson();

for await (const chunk of stream) {
const r = json.push(chunk);
showText(r.value?.response ?? '');
if (isComplete(r, ['items'])) showItems(r.value!.items!);
}
`

value is typed as DeepPartial<Reply>: every field optional, all the way down, because that is what it is until the stream finishes. The compiler then makes you handle the undefined case at every access, which is tedious for about ten minutes and then saves you from the bug where the suggestions render with no names.

The 2024 usage pattern maps onto this almost line for line. extractResponseFromPartialJson(accumulated) becomes json.push(chunk).value?.response, and tryParseCompleteJson becomes checking state === 'complete'. The streaming post's React Native app calls the old function from its chunk handler, one layer above the transport, and swapping it for the new one is a two-line change there too. That app's copy had also grown two more suggestion fields and a renamed one, which is the drift that a package stops.

What the other packages do

There are several partial JSON parsers on npm and I tried four of them against the same inputs before deciding to publish another. The fenced case is the one that separates them.

Input	partial-json	best-effort-json-parser	incomplete-json-parser	jsonrepair
`json\n{"response": "Hello th `

| throws | `{response: "Hello th"}` | throws | `{response: "Hello th"}` | | `Sure! ...\n

json\n{"response": "Hi", "items": [{"id": 1, "na| throws |{response, items: [{id: 1}]}| throws | wraps the preamble and the object in an array | |{"n": 12.|{}|{n: 12}|{n: 12}|{n: 12}| |{"s": "a\u00|{s: "a"}| throws |{s: "a"}|{s: "a"}| |{"response": "done", "lang|{response: "done"}|{response: "done"}| addslang: null| addslang: null` |

Versions as of October 2026: partial-json 0.1.7, best-effort-json-parser 1.5.1, incomplete-json-parser 1.1.5, jsonrepair 3.15.0. The Vercel AI SDK's parsePartialJson is not in the table because it lives inside the ai package and expects bare JSON; it tries JSON.parse, then repairs with a scanner and tries again, and reports one of successful-parse, repaired-parse or failed-parse.

None of them tells you which field is still streaming, and none of them distinguishes a number that is finished from one that is not. Two of them handle fences. If you already depend on jsonrepair for its actual purpose, which is fixing broken JSON rather than completing truncated JSON, it does a reasonable job on this too, though the preamble handling will surprise you.

The playground

The playground loads the same dist/index.js the package ships, so what you see there is what you get from npm. Paste a response or use the sample, press play, and the right-hand pane shows the received text, the state, the streaming path and the parsed value with the live field highlighted. The slider lets you scrub to the exact character where a field appears, which is how I checked most of the rules in the table above. The options panel toggles the fence stripping and the two partial-value rules so you can see what each one does to the same text.

What it does not do

It parses bare JSON when no fence is present, where the app copies of the old function refused to parse anything outside a `


json

block. If you port from one of those and your preamble can contain a brace, passfences: false` or keep the fence in the prompt.

It does not repair invalid JSON. If the model emits a trailing comma the result is invalid, not a best guess, because guessing is a different job and jsonrepair already does it well. It does not validate against a schema; pass the complete value to whatever you use for that. It is not incremental, for the reasons above. And it tolerates one thing JSON.parse does not, which is raw newlines inside strings, because models produce them and rejecting a whole response over one is not helpful.

The source is a single file, shipped inside the package alongside the compiled output, and the tests are in the same style as the examples in this post. MIT licence, as before. If you built one of those variants from the gist, this should replace it without you having to think about escape sequences ever again.

Everything I Automated on This Blog

stepinto.dev — Fri, 16 Oct 2026 14:56:40 +0000

This site is a Hugo build pushed to Azure Static Web Apps from a GitHub Actions workflow. Over the past year the workflow and the templates have grown a handful of jobs that do the chores I used to do by hand after publishing a post. None of it is clever, and most of it is under a hundred lines, but each piece came with one gotcha that cost me an afternoon. Here they are, in the order a post meets them.

Publishing on a date I am not at the keyboard

Hugo skips any post whose date is in the future unless you build with --buildFuture. That is the whole scheduling system. I write a post, give it a Tuesday, and push it with everything else. The build ignores it until the date passes.

The gotcha is that the deploy has no schedule trigger. It runs on push, and that is all. A post dated Tuesday appears on the first push after Tuesday, which might be Tuesday if I remember and Thursday if I do not. I have decided this is fine. A cron trigger that rebuilds every morning would fix it in three lines, and I have left it out on purpose, because a rebuild with nothing new in it is the kind of thing that fires for years after you have forgotten it exists.

The dev server runs with --buildFuture so I can read queued posts, and the plan for the quarter lives in a Markdown table that says which file carries which date.

Share images drawn at build time

Every page gets a 1200 by 630 share image rendered by Hugo itself, with no Puppeteer, no Node, and no image service. The partial takes a base PNG from assets/, draws the series name in blue above the title in white, and publishes the result next to the page as og.png:

{{ $filters := slice
     (images.Text ($kicker | upper) (dict "font" $font "size" 26 "color" "#60a5fa" "x" 80 "y" 120))
     (images.Text $title (dict "font" $font "size" $size "color" "#ffffff" "x" 80 "y" 180 "linespacing" 10)) }}
{{ $img := $base.Filter $filters }}
{{ $img = resources.Copy (path.Join (path.Dir .RelPermalink) "og.png") $img }}

images.Text wraps long lines at the image edge, which I did not expect and was pleased to find. What it does not do is shrink the text to fit, so the partial picks a font size from the title length: 64 pixels up to 45 characters, 56 up to 70, and 48 beyond that. The font has to be a TrueType resource, so JetBrains Mono Bold lives in assets/fonts/. The head partial prefers a hand-made cover image if the front matter has one, falls back to the generated one, and only then to the site hero.

A full build produces about 190 of these. They are regenerated only when the title or the base image changes, because Hugo caches image filters by their inputs, so the build cost is a one-off.

Structured data, and the double escaping

Each post carries a BlogPosting block in JSON-LD so search engines get the headline, dates, author and word count without guessing. My first version wrote the JSON by hand in the template and piped each value through jsonify:

<script type="application/ld+json">
{
  "headline": {{ .Title | jsonify }},
  ...
}
</script>

That looks right and is wrong. Hugo templates are Go's html/template, which knows it is inside a <script> element and escapes anything you print there as a JavaScript string. jsonify had already produced a quoted JSON string, so the escaper quoted it again. A title containing a quotation mark came out as:

{"headline": "\"Why \\\"Barely\\\" Is the Right Word\""}

Valid JSON, and every validator accepted it. The headline was just a string that happened to begin and end with quote marks, and because the page source still parses as JSON it is easy to miss until you read a value back. The fix is to build the whole object as a Hugo dict, serialise it once, and mark the result as safe so the script context leaves it alone:

{{ $ld := dict
  "@context" "https://schema.org"
  "@type" "BlogPosting"
  "headline" .Title
  "datePublished" (.Date.Format "2006-01-02")
  "wordCount" .WordCount }}
<script type="application/ld+json">{{ $ld | jsonify | safeJS }}</script>

The rule I took from it: in a Hugo template, never emit JSON field by field. Make the object, serialise it in one go.

Cross-posting to dev.to

The deploy workflow has a job that runs after the build and calls a small Python script against the Forem API. The script reads the Hugo post, converts it, and creates or updates the matching article on dev.to. It carries no state. Before writing anything it lists every article on the account and matches by canonical_url, so there is no mapping file to keep in sync and nothing to break if I rename a post locally.

The conversions are small:

The canonical URL points back here, so search credit stays on this domain.
Site-relative links and image paths are rewritten to absolute ones. A /posts/foo/ link that works on this site is a dead link on dev.to.
Tags are lowercased, stripped to alphanumerics, deduplicated, and cut to four. Dev.to allows four tags made of letters and digits only, so react-native becomes reactnative and a post with six tags loses its last two.
The series slug is mapped to the series title from the section's index file.
Posts with no description get one from the first paragraph, trimmed to 150 characters.

The job distinguishes between added and modified files in the push. New posts are created. Edited posts are only pushed if an article already exists for them, so fixing a typo in a 2024 post never creates a 2024 post on dev.to with today's date. The script waits three seconds between writes and backs off on a 429, because the API throttles article writes.

The --dry-run flag prints the converted payload and calls nothing. I run it on every new post before pushing, mostly to see what the tag mangling has done.

Newsletter drafts

A second job watches for added posts and creates a Buttondown email for each, with the title and a link. It creates them with status: draft, not about_to_send, so I open Buttondown, add a sentence or two, and send it myself. Fully automatic sending from a CI job felt like the kind of thing that emails every subscriber a half-finished post at 2am.

This job has a bug I know about and have left alone. It finds new posts by diffing the last commit against its parent. A push that carries three commits only sees the last one, so a post added two commits back gets no draft. The dev.to job does this properly, by diffing from the commit the push started at, which GitHub puts in the event payload. One day I will make the newsletter job do the same. Until then I push posts one commit at a time, which I was doing anyway.

Markdown and plain text alongside the HTML

Every post is also published as index.md next to its index.html, from a four-line template that emits the title, description, date and the raw Markdown source. The "Copy as Markdown" button at the top of each post fetches that file and puts it on the clipboard, and prefetches it on hover so the click feels instant. The site root also serves llms.txt, a plain list of every post with a one-line summary and a link to its Markdown, for whatever reads those.

The one thing to know is that Azure Static Web Apps rewrites unknown paths to index.html for single-page apps, so the config has to exclude .md, .txt, .xml and .json from the fallback and declare their MIME types, or your Markdown comes back as your home page.

A hand crank

The workflow also runs on workflow_dispatch. I added that after a deploy failed on the hosting side, with nothing wrong in the commit, and the only way to retry was an empty commit. One button in the Actions tab is better than that.

What I have not automated

Posting to Hacker News, Reddit, Bluesky and LinkedIn is still me, by hand, on the morning of. Each of those wants a different sentence and a different time of day, and the ones I have seen automated read like it. The analytics check is also manual: two counters, three numbers, Monday morning. That is probably the right amount of automation for a blog, which is a thing I write rather than a thing I operate.

Range-Over-Func Iterators for People Who Miss LINQ

stepinto.dev — Fri, 16 Oct 2026 13:34:41 +0000

The most common complaint in the comments on this series, and the first item in what I miss from C#, is LINQ. That post shows this:

var activeUsers = users
    .Where(u => u.IsActive)
    .OrderBy(u => u.Name)
    .Select(u => new { u.Id, u.Name })
    .ToList();

and then the for loop and the sort.Slice call you wrote instead. Go has had range-over-func iterators since 1.23, the standard library has been growing functions that return them in every release since, and Go 1.27 removed the one language restriction that made a fluent chain impossible. This post is the honest side by side. Every snippet runs.

What an iterator is in Go

In C#, IEnumerable<T> is a pull model. The consumer holds an enumerator and calls MoveNext() until it says no. A yield return method is compiled into a state machine that implements that interface for you.

Go went the other way. An iterator is a function that takes a callback:

type Seq[V any] func(yield func(V) bool)

The iterator pushes values into yield, and yield returns false when the consumer wants to stop. The for range statement knows how to drive one:

func Naturals() iter.Seq[int] {
    return func(yield func(int) bool) {
        for i := 0; ; i++ {
            if !yield(i) {
                return
            }
        }
    }
}

for n := range Naturals() {
    if n > 3 {
        break   // yield returns false, the iterator returns, nothing leaks
    }
    fmt.Println(n)
}

That is the whole mechanism. The body of your for loop becomes the yield function. break becomes yield returning false. There is no state machine and no interface, which is why the compiler can inline simple cases and why the design went through so many rounds before it shipped.

There is also iter.Seq2[K, V] for pairs, which is what maps.All and slices.All return, and iter.Pull for the rare case where you really do need MoveNext() semantics, at the cost of a goroutine-like coroutine behind the scenes. You will almost never want it.

What the standard library gives you

Sources and sinks, mostly. No adapters.

slices.Values(s)        // iter.Seq[E]
slices.All(s)           // iter.Seq2[int, E]
slices.Backward(s)
slices.Chunk(s, n)
maps.Keys(m)
maps.Values(m)
maps.All(m)
strings.Lines(s)        // Go 1.24
strings.SplitSeq(s, sep)
strings.FieldsSeq(s)

slices.Collect(seq)     // []E
slices.Sorted(seq)      // []E, sorted
slices.SortedFunc(seq, cmp)
maps.Collect(seq2)      // map[K]V

So the first thing LINQ people reach for already works:

keys := slices.Sorted(maps.Keys(m))

That line replaced a nine line function in half the Go codebases I have worked in.

What is missing is Where, Select, Take, First and friends. The proposal to add them as x/exp/xiter was withdrawn after a long argument about whether adapters encourage over-abstraction. There is a decent chance they come back once the community has settled on idioms. For now you write them, and they are short.

Writing Where and Select

func Where[T any](seq iter.Seq[T], keep func(T) bool) iter.Seq[T] {
    return func(yield func(T) bool) {
        for v := range seq {
            if keep(v) && !yield(v) {
                return
            }
        }
    }
}

func Select[T, U any](seq iter.Seq[T], f func(T) U) iter.Seq[U] {
    return func(yield func(U) bool) {
        for v := range seq {
            if !yield(f(v)) {
                return
            }
        }
    }
}

Each one is a function that returns a function. The !yield(v) check is the only line that matters: it is what lets a break three layers up stop an infinite source at the bottom.

func First[T any](seq iter.Seq[T]) (T, bool) {
    for v := range seq {
        return v, true
    }
    var zero T
    return zero, false
}

first, _ := First(Where(Naturals(), func(n int) bool { return n > 100 }))
// 101, and Naturals stopped at 101

Lazy, composable, early-terminating. All three properties the "what I miss" post said Go did not have.

The example, rewritten

With those two helpers and slices.SortedFunc, the LINQ query from the top becomes:

active := slices.SortedFunc(
    Select(
        Where(slices.Values(users), func(u User) bool { return u.IsActive }),
        func(u User) UserSummary { return UserSummary{u.ID, u.Name} },
    ),
    func(a, b UserSummary) int { return cmp.Compare(a.Name, b.Name) },
)

It does the same thing. It is lazy until the sort. And it reads inside-out, which is the complaint everyone has about it within five minutes. In C# the pipeline reads top to bottom because Where and Select are extension methods on the sequence. In Go, up to 1.26, there were two reasons you could not do that:

You cannot define methods on a type from another package, so nothing can hang off iter.Seq directly. You need your own named type.
Methods could not have their own type parameters, so even on your own Query[T] type, a Select that returns Query[U] was impossible to declare. That is the one that killed every attempt at a fluent LINQ in Go.

The first restriction is permanent and the workaround is one line. The second one is gone.

Go 1.27 and generic methods

As of August 2026 a method can declare type parameters of its own. So this is now legal:

type Query[T any] iter.Seq[T]

func From[T any](s []T) Query[T] { return Query[T](slices.Values(s)) }

func (q Query[T]) Where(keep func(T) bool) Query[T] {
    return func(yield func(T) bool) {
        for v := range q {
            if keep(v) && !yield(v) {
                return
            }
        }
    }
}

func (q Query[T]) Select[U any](f func(T) U) Query[U] {
    return func(yield func(U) bool) {
        for v := range q {
            if !yield(f(v)) {
                return
            }
        }
    }
}

func (q Query[T]) OrderBy(cmp func(a, b T) int) Query[T] {
    return From(slices.SortedFunc(iter.Seq[T](q), cmp))
}

func (q Query[T]) ToSlice() []T { return slices.Collect(iter.Seq[T](q)) }

And the query reads the way your C# brain wants it to:

active := From(users).
    Where(func(u User) bool { return u.IsActive }).
    OrderBy(func(a, b User) int { return cmp.Compare(a.Name, b.Name) }).
    Select(func(u User) UserSummary { return UserSummary{u.ID, u.Name} }).
    ToSlice()

Type inference fills in U from the function you pass, so you never write Select[UserSummary]. The two caveats from the release notes: an interface still cannot declare a generic method, and a generic method cannot satisfy an interface. For a query type that is irrelevant. For anyone hoping to write IQueryable, it is the end of the road, and honestly good.

Whether you should build this is a separate question. The Go answer is still that a pipeline of three steps is a for loop with three lines in it, and the loop is easier to debug. Where Query earns its keep is the same place LINQ does: when the pipeline is the point, when it is reused, or when the source is lazy and you want First to stop it.

What it costs

Each stage of the pipeline is an indirect function call per element. The compiler inlines the simple cases but not a chain of closures. Filtering and projecting a hundred thousand structs on Go 1.25, three runs each:

	ns/op	allocs/op
for loop with append	500,000	23
`Collect(Select(Where(Values(...))))`	920,000	33

Roughly double on a benchmark that does nothing but iterate. In a real handler the database round trip dwarfs it. It is the same trade LINQ makes against a foreach, and the same answer: write the pipeline, profile before you unroll it.

The honest table

LINQ	Go now	Notes
`Where`	write it, 8 lines	or `Query.Where` on 1.27
`Select`	write it, 8 lines	generic method needs 1.27
`OrderBy`	`slices.SortedFunc`	materialises, same as LINQ
`First` / `FirstOrDefault`	write it, 6 lines	returns `(T, bool)`
`Take` / `Skip`	write it	easy, counter in the closure
`Any` / `All` / `Count`	loop or write it	three lines each
`ToList`	`slices.Collect`
`ToDictionary`	`maps.Collect`	from a `Seq2`
`Distinct`	`slices.Sorted` + `slices.Compact`	or a map, if order matters
`GroupBy`	write it, returns `map[K][]T`	no lazy grouping
`Zip` / `Join`	`iter.Pull` on one side	ugly, write the loop
`Aggregate`	loop	a fold is a loop
`SelectMany`	nested `range` in a closure	fine
`IQueryable`	nothing	and nothing coming

Everything in the "write it" column is under ten lines and lives in one file in your module. There are third-party packages that have already written them, and the lo library the old post mentioned now has an it subpackage built on iter.Seq, but a dependency for forty lines of code is a bad Go instinct and the standard library may yet absorb them.

What I would say now

The "what I miss" post said Go's approach "lacks the expressiveness" of LINQ. In 2024 that was fair. In 2026 the laziness and composition are there, the standard library sources and sinks are there, and generic methods mean the fluent form is a type definition away. What is still missing is the adapters in the box and the convention that everyone uses the same ones, which is the thing that makes LINQ readable across codebases rather than just within one.

So: less missing than I said. Not gone. Write the eight lines, keep the loop for the simple cases, and do not import a query language.

Forty-Eight Posts on Moving From C# to Go, in the Right Order

stepinto.dev — Fri, 16 Oct 2026 13:34:37 +0000

The C# to Go series is forty-eight posts long. It covers the move from twenty years of .NET to writing Go in production, from the first go build through to a six month retrospective, and it is the most-read thing on this site by a distance.

It was written as a sequence, but most readers do not arrive at the start of it. They arrive from a search for "Go equivalent of IOptions" and land on the configuration post, with no signpost to the twenty posts that explain the vocabulary it uses. The series page lists everything by date, which is correct and unhelpful.

So there is now a landing page at /go-for-csharp-developers/ that orders the whole thing as chapters. This post explains what is on it, who it is for, and what has changed in Go since.

Who it is for

You know C# well. You have shipped ASP.NET Core services, you have opinions about Entity Framework, and you can explain ConfigureAwait(false) to a junior without looking it up. You are either curious about Go or you have just been handed a Go codebase and need to be productive in it by the end of the month.

The series assumes all of that. It does not explain what a slice is from first principles. It explains what a slice is to someone who thinks in List<T>, including the shared backing array behaviour that catches every single one of us. Each post takes a thing you already know in .NET and shows the Go shape of it, where the shape is different, and where your muscle memory will hurt you.

If you do not know C#, the posts still work, but half the jokes will be lost on you.

How to read it

Start with the phrasebook. It maps C# vocabulary to Go vocabulary in one table and takes ten minutes. Bookmark it. Every other post uses the Go words without stopping to translate.

After that, read by chapter. The landing page groups the posts like this:

Getting started. The toolchain, modules instead of csproj, and the phrasebook.
Types. Structs instead of classes, visibility by capitalisation, the enum situation, generics, and nil.
Control flow and errors. The switch statement, if err != nil, and why panic is an emergency exit rather than an exception.
Memory. Pointers, slices, and escape analysis for people who have never thought about the stack.
Concurrency. Goroutines against async/await, channels, select, context, and the sync package for when channels are the wrong tool.
Interfaces and composition. Implicit interfaces, embedding instead of inheritance, and the empty interface.
Testing and project layout. The built-in testing package, mocking without Moq, benchmarks, organising a real project, and multi-module repos.
Building services. net/http, JSON, database/sql, GORM, configuration, and logging.
Tooling. Linting, debugging with Delve, and code generation.
Deployment. Single binaries, build tags, Docker, Kubernetes, health checks, Lambda, observability, GitHub Actions, and versioning.
Looking back. What I miss, what I will never go back for, and the six month retrospective.

If you are in a hurry, chapters one, two, three and five are the ones that change how you think. The rest you can read when the relevant problem turns up.

Three things I would write differently now

The series was written against Go 1.22 and 1.23. Go is now at 1.27 and .NET is at 10, and three of the posts read differently against the current toolchain. The smaller version drift (image pins in Dockerfiles, the golangci-lint config format, b.N loops where b.Loop() now goes) gets a short post of its own at Christmas. These are the three that change the argument.

LINQ has a real answer now

The phrasebook's row for LINQ says "nothing built-in", and the "what I miss" post opens with "God, I miss LINQ" and shows the for loop you write instead. That was the honest position for production Go at the time. Range-over-func iterators had only just landed in 1.23 and the standard library had barely started using them.

It has caught up. The slices and maps packages have grown iterator-returning functions in every release since, strings.Lines and SplitSeq arrived in 1.24, and a lazy pipeline is now a thing you can write without a third-party package. Whether it reads as well as Where().Select().First() is a different question, and that one gets a full post in December with an honest side by side.

Meanwhile C# 14 shipped extension members, so the extension methods gap got wider from the other direction. Fair is fair.

Container-aware GOMAXPROCS is real now, and the Kubernetes post needs a date fixed

The Kubernetes post says Go has respected container CPU limits since 1.19. The 1.19 change was GOMEMLIMIT, which covers memory. CPU awareness arrived in Go 1.25 in August 2025. Before that, a Go process in a container with a two core limit on a sixty-four core node would set GOMAXPROCS to sixty-four and spend its life being throttled, and the fix was Uber's automaxprocs library.

On any toolchain from the last year the post's advice holds as written. If you are running something older in Kubernetes, that is the first thing to check. It is the kind of mistake that costs money quietly.

JSON got a new engine and the tag everyone wanted

The JSON post spends a whole section on the omitempty gotcha, where a zero is treated as empty and silently dropped from the output, and reaches for a pointer to work around it. Go 1.24 added omitzero, which does what everyone assumed omitempty did. The pointer trick still works. It is no longer the right answer.

Then Go 1.27 switched encoding/json over to the v2 implementation underneath. Decoding is a good deal faster and the API you call is the same, but the defaults are stricter: duplicate keys and invalid UTF-8 in strings are now errors rather than things that quietly passed. If you are moving a service that consumes JSON from systems you do not control, test that first after you bump the toolchain. Coming from System.Text.Json, which is also strict by default, you will probably find the new behaviour more familiar than the old.

The whole thing as a PDF

The forty-eight posts come to a little over two hundred pages when laid out as a book, with the chapters above as sections and the phrasebook as an appendix. It is the version I would have wanted on the train in week one.

It goes to newsletter subscribers. The signup form is at the bottom of this page, and the download link arrives in the welcome email. The newsletter is one email a week, on a Tuesday, when a post goes out, and nothing else.

If you have made the same move and want a post that is not here, say so. The Christmas post is the corrections and additions, and the comments on the series have written half of it already.

A World Model in Forty Lines of TypeScript

stepinto.dev — Thu, 15 Oct 2026 13:56:58 +0000

Every explanation of world models I've read starts the same way. A conditional probability, a subscript, a latent variable, and half the audience gone by paragraph three. Which is a shame, because the core idea fits in a few lines of code and most working programmers already have the intuition. They've just never had it pointed at.

So this series starts with TypeScript. We'll get to the equations eventually, but only once they're describing something you've already watched run. (If you'd rather have today's ideas with no code at all, the previous post covers the same ground in prose.)

The whole idea, in code

A world model answers one question: if the world looks like this, and I do that, what happens next?

State in, action in, predicted next state out. Here's the smallest honest version I can write, using a domain I spend a lot of my life in: a room with a heater.

type State = {
  roomTemp: number;     // °C
  outsideTemp: number;  // °C
  heaterOn: boolean;
};

type Action = "turnHeaterOn" | "turnHeaterOff" | "wait";

function predict(state: State, action: Action): State {
  const heaterOn =
    action === "turnHeaterOn" ? true :
    action === "turnHeaterOff" ? false :
    state.heaterOn;

  // Heat leaks towards outside; the heater pushes back.
  const leak = (state.outsideTemp - state.roomTemp) * 0.1;
  const heat = heaterOn ? 1.5 : 0;

  return {
    roomTemp: state.roomTemp + leak + heat,
    outsideTemp: state.outsideTemp,
    heaterOn,
  };
}

predict is a world model. A hand-written, embarrassingly simple one, but structurally the real thing: it takes a state and an action and returns the next state. The fancy research systems (DreamerV3, LeCun's JEPA work, NVIDIA's Cosmos line) are this same function signature with the body learned from data instead of typed by me, and with State replaced by something the model invents for itself. We'll unpack both of those moves later in the series. The shape doesn't change.

And once you have that function, you get the properly useful trick for free: you can run the future without touching the present.

function rollout(start: State, actions: Action[]): State[] {
  const trajectory = [start];
  for (const action of actions) {
    trajectory.push(predict(trajectory[trajectory.length - 1], action));
  }
  return trajectory;
}

const cold: State = { roomTemp: 14, outsideTemp: 5, heaterOn: false };

// What happens if I turn the heater on and leave it?
rollout(cold, ["turnHeaterOn", "wait", "wait", "wait"])
  .map(s => s.roomTemp.toFixed(1));
// [ '14.0', '14.6', '15.1', '15.6', '16.1' ]

No heater was harmed. We asked "what if?" four steps deep and got an answer in microseconds. Planning, in the world-model sense, is exactly this: propose a few candidate action sequences, roll each one forward inside the model, pick the future you like best, then execute only the first action for real.

Action-result pairs are the raw material

My predict function encodes physics I made up. A real world model learns its predict from logged experience, and the unit of experience is the action-result pair: I was in state s, I did action a, I ended up in state s'.

type Transition = {
  state: State;
  action: Action;
  nextState: State;
};

const experience: Transition[] = [
  {
    state: { roomTemp: 14.0, outsideTemp: 5, heaterOn: false },
    action: "turnHeaterOn",
    nextState: { roomTemp: 14.6, outsideTemp: 5, heaterOn: true },
  },
  {
    state: { roomTemp: 14.6, outsideTemp: 5, heaterOn: true },
    action: "wait",
    nextState: { roomTemp: 15.1, outsideTemp: 5, heaterOn: true },
  },
  // ...thousands more
];

Training a world model means fitting a function to this table: given the first two columns, predict the third. Which is just supervised learning with free labels, because the world hands you the answer one timestep later. Nobody annotates anything.

If you run devices in the field, look at that Transition type again. It's a telemetry log with the actuator commands joined on. Every thermostat, pump controller and battery system that's been logging sensor readings alongside its control decisions has been accumulating world-model training data for years. This is a big part of why I care: at Unimo we live in exactly this stream of readings and commands from energy hardware, which is the realisation the previous post was built around. The boring operational log is also the training set.

So how is this different from an LLM?

An LLM is also a next-thing predictor, so it's fair to ask what's actually new here. Two things, and the first is the one I think matters most.

Statefulness. An LLM has no memory of its own. Every API call, you hand it the entire conversation and it recomputes everything from scratch, predicts some tokens, and forgets you existed. The "state" of your chat lives in your database, not in the model. It's a pure function over a context window, and when the conversation outgrows the window, the model's grip on what's true starts to slip. Anyone who's built an agent that gradually forgets what it did twenty steps ago has felt this.

A world model is stateful by construction. It carries a compact internal state forward from step to step, updating it as actions happen and observations arrive. Ask it about step 500 and it doesn't need to rummage through 500 steps of history, because everything that still matters is already folded into the current state.

Actions are first-class. For an LLM, an action is just more text. A tool call is tokens out, a tool result is tokens in, and the model must infer from prose what its action did. A world model takes the action as an explicit, typed input (the a in predict(s, a)) and is trained specifically on what actions do. Cause and effect is the whole curriculum rather than something absorbed second-hand from prose about other people's causes and effects.

Side by side:

	LLM	World model
Predicts	next token	next state
Given	a context window of text	current state + an action
State between calls	none, resent every time	persistent, carried forward
"What if?"	narrates a plausible story	rolls the trajectory forward
Learns from	mostly static text	logged action-result pairs

Ask an LLM what happens if you turn the heater on and it will tell you a story about the room warming up, and it will be a good story, statistically resembling the millions of similar stories in its training data. Ask a world model and it runs it, the same way our rollout did. For chatting, the story is fine. For deciding whether to actually flip a relay on hardware you're responsible for, I want the simulation.

To be fair to LLMs, they do pick up something world-model-ish internally. Interpretability work has found neurons in Llama-family models tracking space and time surprisingly well. But those representations are passive and rebuilt from scratch on every call. Having read a lot about rooms is not the same as tracking the temperature of this one.

Where this series goes

This post is deliberately the shallow end. My predict cheats in ways that stop mattering only in toy problems: the state is three fields I chose by hand, the dynamics are made up, and nothing is learned. Real systems have to invent their own state representation from messy high-dimensional observations, learn the transition function from logs, and avoid some entertaining failure modes while doing it (there's one called representation collapse, where the model discovers it can score perfectly by declaring every state identical, which is the ML equivalent of a student answering every question with "no change").

Roughly where we're headed:

The code-free introduction and this post. State, actions, rollouts. The function signature.
Learning predict from data. Replacing my hand-written physics with a fitted model, still in TypeScript, still no notation. Published December 2026, with a playground that fits the model in your browser.
Latent states. What happens when the state is a sensor array or camera frame and the model has to compress it itself. This is where the field gets interesting and where the maths finally earns its keep.
The open-source landscape. DreamerV3, JEPA and friends, what you can run on your own hardware, and why that matters more than it first appears.
World models and physical devices. Where the action-result firehose from real hardware meets all of the above.

If you take one thing from today, take the function signature. An LLM completes your text. A world model, given where you are and what you're about to do, tells you where you'll be. Everything else in this series is elaboration on that difference.