A migration guide titled “Go to Rust” hit the front page of Hacker News this week, collecting 362 upvotes and over 350 comments. It is, by all accounts, a competent piece of technical writing — thoughtful, well-structured, the kind of resource that makes a senior engineer nod along. What it does not contain, anywhere in its pages, is a dollar figure.
Not the salary of the engineers who wrote the original Go services. Not the opportunity cost of pulling them off feature work for months. Not the cost of the bugs introduced during the port, or the regressions caught in staging, or the incidents that will happen in production because the new code doesn’t handle edge cases the old code learned about the hard way over three years of runtime. The guide is free. The migration it describes is anything but.
The Engineering Blog as Cost-Externalization Machine
There is a genre of technical writing — call it the migration confessional — that follows a rigid template. Step one: describe the old system in terms just respectful enough to avoid sounding ungrateful. Step two: enumerate its deficiencies with the clinical precision of an autopsy. Step three: unveil the new system, built in a language or framework that was not production-viable when the original system was first written. Step four: declare victory. Latency down. Throughput up. Memory footprint halved.
The genre has a curious omission. It never includes a line item for what the original system cost to build, maintain, and operate. It never says: three engineers, eighteen months, $900,000 in loaded compensation, and by the way, it worked fine for four years before we decided it was embarrassing.
The migration guide, as a form, treats the original system as sunk cost — literally, in the accounting sense. The money is gone, so it does not factor into the decision. But sunk cost is a concept from capital budgeting, not from organizational health. When a team rewrites a working system and publishes a blog post about it, they are not just discarding code. They are discarding institutional knowledge, accumulated operational wisdom, and the careers of the people who built the thing that is now being described as a cautionary tale.
The People Who Wrote the Go Code Are Not Writing the Blog Post
“The original Go services had become difficult to extend,” the guide explains, in the passive voice that does so much quiet work in this genre. Difficult for whom? The guide’s author, presumably. The team that inherited the code, not the team that wrote it.
This is the hidden shape of most migration stories. The people who chose Go — who argued for it in the architecture review, who defended it when the Rust evangelists came knocking in 2023, who trained the junior engineers on goroutines and channels — those people are often gone by the time the migration begins. They left for other companies, or other teams, or were let go in one of the industry’s rolling restructurings. Their code outlived their employment, and then their code was replaced.
The migration guide’s author inherits a system they did not choose, evaluates it against criteria the original authors were not optimizing for, and concludes it is deficient. This is not engineering. It is archaeology with a wrecking ball.
One engineer who left a mid-sized fintech company after a similar rewrite told me, in a Slack DM after his notice period ended, “I spent two years building the payment pipeline. The new CTO called it ‘legacy’ in an all-hands six weeks after I left. They rewrote it in six months. The rewrite went over budget by 40 percent and missed three launch dates. But the blog post got 800 upvotes, so I guess it was worth it.”
What Gets Measured
Latency percentiles go in the migration guide. So do memory profiles, throughput benchmarks, and lines-of-code comparisons. What does not go in: the number of customer-facing features that were delayed because the team was rewriting instead of building. The number of engineers who quit because they wanted to work on product, not on a port of something that already worked. The number of production incidents traceable to the new system’s unfamiliarity — not because Rust is bad, but because any replacement system is less battle-tested than the one it replaces.
A Rust advocate reading this will object: but the old system was unsafe. Memory bugs. Data races. Concurrency footguns. These are real concerns. They are also concerns that can be addressed through tooling, process, and incremental improvement — approaches that do not generate conference talks but do generate working software.
The migration guide promises safety. It delivers safety against a particular class of bugs that the Go team had presumably learned to avoid through painful experience. The cost of re-learning those lessons in a new language is not zero. It is simply not measured.
The Industry’s Real Technical Debt Is Its Relationship With Prestige
The Hacker News thread beneath the guide is full of engineers debating whether Go’s simplicity is a feature or a ceiling. This is the conversation the migration guide wants you to have — because it makes the rewrite sound like a technical decision rather than a cultural one.
But the decision to migrate from Go to Rust is rarely made in a vacuum. It is made by engineers — and engineering leaders — who are tired of writing Go. Who find Rust more interesting. Who want the Rust line on their résumé. Who believe, correctly or not, that the market will reward Rust expertise more handsomely than Go expertise in the years ahead.
This is not a critique of Rust. It is a critique of an industry that celebrates rewrites while treating maintenance as a cost center. The engineer who kept the Go system running for five years — patching it, monitoring it, learning its quirks, training new hires on it — does not get a front-page blog post. The engineer who replaces it does.
Until the migration guide includes a section titled “What This Cost and Who Paid For It,” the genre will remain what it is: a victory lap for the people who arrived after the hard work was done.