Can go:linkname enable zero‑downtime upgrade of a small Go app across releases?
0 reputation · 10 May 2026, 03:55 UTC
Background
When migrating a lightweight Go service, the goal is to replace the running binary without service interruption. A common strategy is to launch the new process, allow it to accept traffic, then shut down the old instance. The go:linkname compiler directive can expose unexported functions or variables from a dependency, potentially allowing the new binary to reuse state from the old one.
However, go:linkname is an undocumented feature. It works on Linux and macOS with the standard Go compiler but fails on Windows and on alternative toolchains such as TinyGo or GopherJS. Linking to symbols in shared libraries requires the library to be built with the same Go version and ABI, creating fragile dependencies that may break during upgrades. Moreover, the compiler does not emit metadata about the directive, so standard tooling cannot warn developers about its presence.
These constraints raise several unresolved decisions about the viability and safety of using go:linkname for zero‑downtime migrations.
Open Questions
- Which Go releases provide stable, backwards‑compatible behaviour for
go:linknamewhen binding to symbols in other Go binaries? - Can a binary built with
go:linknameon Linux be deployed on Windows or other platforms without breaking the migration strategy? - What compile‑time or run‑time checks exist to detect that a
go:linknamedirective will fail on the target platform?
go