The Accidental Application Runtime: when a Go service quietly becomes more than an HTTP server

A fairly ordinary Go service can gradually end up owning polling loops, schedulers, workers, shared state, and shutdown—not because anyone designed an application runtime, but because the setup code was where all the dependencies happened to meet. I wrote about recognising that transition and making the architecture explicit. The article starts with a small 3D-print farm, takes a short detour through PX4, then builds a typed in-process backplane in Go using ordinary function signatures. The library itself isn’t really the point. The more interesting part is separating contracts that are easy to blur together: calls versus messages, streams versus current state, and durable truth versus in-memory notification. I’d be interested to hear where people think this sort of abstraction stops paying for itself, or what patterns you’ve used instead.