Appwrite rewrites its CLI from TypeScript to Go
A concrete developer-tools rewrite story where the useful result is less about language ideology and more about startup time, install surface, memory use, release targets, and compatibility discipline.
Links: Original source · Shared link · Related link
Logged at IST: 2026-08-13 09:59 IST
What it is: Richard Seroter pointing to Appwrite's rewrite of its CLI from TypeScript/Bun to Go.
Gist: Appwrite says the user-facing contract stays the same: npm package name, appwrite binary, flags, scripts, CI behavior, exit codes, and JSON output. The internals changed from a JavaScript bundle on a runtime plus 189 packages underneath to a native Go binary.
The measured deltas are the useful part: startup went from 207.6ms to 11.1ms, install dependency count from 330 packages to 2, on-disk install from 209MB to 13MB, memory during push from 283.5MB to 28.0MB, and binary size from 66MB to 14MB. Appwrite frames the memory drop as an implementation change too: the new CLI streams the archive instead of holding it in memory.
The Go-versus-Rust rationale is pragmatic rather than ideological. Appwrite says both languages would have solved the ~200ms startup cost, but Go fit because the CLI mostly does parallel network operations, the first-party Appwrite Go SDK already comes from the same generator, GOOS/GOARCH covers their six release targets, and community contributors can ramp quickly. They kept the TypeScript CLI installable for at least one minor cycle and used parity tests to compare the two implementations command by command.
Newsletter angle: Useful developer-tools systems item: CLIs are part of product latency and dependency surface. Rewrites are risky, but generated parity tests plus API-spec-derived commands make this a cleaner example than a generic "rewrite in Go" victory lap.