Why we write small server tools in Go now: lessons from a Dart port

Picto.Video has a small analytics tool that runs on a small droplet. It reads raw usage events and builds one SQLite database, and our reports read from that database. We wrote it in Dart. This autumn we moved it to Go. AI coding agents wrote the Go version, and we checked it against the Dart version row by row.

Why Go suits small server tools when agents write the code

Agents now write most of the code for tools like this one. So we judge a language by what happens after the code is written.

The compiler checks the agent's work

Go is statically typed, and its compiler rejects unused imports and unused variables. An agent gets that feedback in seconds, and fixes it before a person sees the code. A Python script finds a wrong type or a misspelt name when that line runs, which on a server tool can be days later. Dart is typed too, so this point is mostly about Python.

The binary is the whole deploy

GOOS=linux GOARCH=amd64 go build on a laptop gives one static Linux binary. Our port has one direct dependency, a SQLite driver written in pure Go, so the build needs no C compiler. The binary is 6.6 MB, and the server needs nothing else installed. A Python script needs an interpreter and its packages on the server, and those drift over time. Dart can also compile to a native binary, and the old tool ran that way.

Memory stays low

We gave the port a budget of 200 MB peak memory on the full data, because a background tool on a shared droplet has to leave room for everything else. Go peaked at 83 MB. Dart peaked at 196 MB on the same input.

The code says what it does

Go makes you choose the things Dart decided for you. Map iteration order is random on purpose, so any code that needs an order has to sort. JSON numbers keep their literal form unless you format them. In the port, every one of those choices is a line you can read. The table further down lists them.

The extra length costs little

The Go port is 2.3 times the line count of the Dart one. An agent wrote those lines in minutes. A person still reads them. Go code reads the same way in every file: the call, then the error check on the next line. That makes a long file quick to review.

How we checked the port

Before the agent wrote any Go, we decided what "done" means. The Go tool has to write the same database as the Dart tool, every table and every row.

1. We copied the production inputs to a laptop, read-only.
2. We built both tools from the same commit.
3. We ran each one on its own copy of the inputs, with the clock zone set to UTC.
4. We dumped every table and view of both databases in a fixed order and diffed the dumps.
5. We measured each run with /usr/bin/time -l.

The diff skips the two values that hold the time of the run. To test the diff itself, we changed one value in a copy of a database. The diff caught it.

The stored CREATE statement of every table, index and view matched as well. That includes a column the schema upgrade adds with ALTER TABLE.

We then ran the Linux build inside a Linux container. The diff came back empty again, and peak memory on the full history was 76.3 MB.

Memory and time

These figures come from the laptop. Peak RSS is the most physical memory the process held at one time.

Go used 42% of the memory Dart used on the full history. Speed came out about even. Go was a little faster on the full build and a little slower on the short runs.

Where Dart and Go differ

Most of the work went into small things the two standard libraries do differently. Each one would have shown up in the diff.

One difference is left. Take a JSON string that holds a lone \ud800 escape. Dart keeps the escape and Go stores U+FFFD. Our data has no such string, so we left it.

What we learnt

• The old tool's defaults were the spec. Nobody chose Dart's key order or its number format. Our reports depended on both anyway. A port has to copy what the old code did, and that includes what its libraries did.
• Write the check before the port. The agent wrote the Go tool, its tests and a harness for the Dart reference output in about 25 minutes. Our trust came from the diff.
• Test the check. A diff that always says "no difference" proves nothing. One planted change showed ours works.
• Write down the differences you accept. The lone \ud800 case is documented, with the reason we left it.
• Run the real build in the real shape. The laptop build passed first. The Linux binary in a container is the one that ships, so we diffed that one too.

Tests and size

We ported all 42 Dart tests to Go with the same names and fixtures, and all 42 pass. We also ran 519 edge-case inputs through both tools. Every output matched.

Where it is now

The Go tool runs in production now, in place of the Dart one.