Can go:linkname enable zero‑downtime upgrade of a small Go app across releases?

Direct Answer

No. The //go:linkname directive cannot enable zero‑downtime upgrades between separate Go binaries. It is a compile‑time linker directive that resolves symbols within a single binary, not a runtime mechanism for sharing memory or state across process boundaries.

Why It Doesn't Work

1. Separate Memory Spaces

Each Go binary runs in its own OS process with a completely isolated virtual address space. //go:linkname merely tells the linker "treat this local symbol as an alias for that external symbol" at build time. It creates no runtime bridge, no shared memory segment, and no IPC channel. When the old process exits, its memory is reclaimed by the OS; the new process starts with a fresh heap.

2. Static Linking by Default

Go produces statically linked binaries by default. Even if you built both versions as shared libraries (-buildmode=shared), the Go runtime does not support dynamic symbol resolution across processes for unexported symbols, and the ABI is not guaranteed stable across releases.

3. The Directive Is Internal and Unstable

• Requires import _ "unsafe" to compile — a deliberate signal that you are opting out of Go 1 compatibility guarantees.
• Symbols can be renamed, removed, or changed in any Go release (including point releases) without notice.
• Behavior differs across platforms (fails on Windows, TinyGo, GopherJS, WASI).
• No compile‑time or runtime validation exists to warn you that a linked symbol has disappeared or changed signature.

What Actually Works for Zero‑Downtime Upgrades

Proven patterns that do work for Go services:

1. Socket / File Descriptor Passing — The old process passes the listening socket (via SCM_RIGHTS on Unix) to the new process before exiting. The new process inherits the socket and continues accepting connections without dropping any. Libraries: facebookgo/grace, tylerb/graceful.
2. External Load Balancer / Proxy — Run both versions behind a load balancer (Envoy, NGINX, HAProxy, cloud LB). Shift traffic gradually (canary/blue‑green). No code changes required.
3. Systemd Socket Activation — systemd holds the listening socket; on restart it hands the socket to the new instance. Works with Type=notify and ListenStream=.
4. Application‑Level State Externalization — Move mutable state out of process memory (Redis, PostgreSQL, etcd, SQLite with WAL). The new binary reads the same external state on startup.

If You Still Want to Explore go:linkname (Not Recommended)

If you are determined to verify the limitation yourself, the minimal test is:

// old/main.go
package main
import _ "unsafe"
var Secret = "v1-state"
//go:linkname Secret main.Secret
func main() { select{} } // keep running

// new/main.go
package main
import _ "unsafe"
var Secret string // expects to link to old's Secret
//go:linkname Secret main.Secret
func main() { println(Secret) } // will NOT see old's value

Build both, run old, then in another terminal run new. The new binary will either fail to link (missing symbol) or print an empty string — confirming no cross‑process access.

One Diagnostic Detail That Would Change the Recommendation

Are you trying to share state within a single process (e.g., hot‑reloading a plugin loaded via plugin.Open), or genuinely across separate OS processes for a service upgrade? The answer above assumes the latter. If it's the former, //go:linkname still isn't the right tool — use plugin package with exported symbols or a shared interface.

Summary

Approach	Works Across Processes?	Stable Across Go Versions?	Production Ready?
go:linkname	❌ No	❌ No	❌ No
FD Passing (graceful)	✅ Yes	✅ Yes	✅ Yes
Load Balancer / Proxy	✅ Yes	✅ Yes	✅ Yes
Systemd Socket Activation	✅ Yes	✅ Yes	✅ Yes
External State Store	✅ Yes	✅ Yes	✅ Yes

Use one of the proven patterns in the bottom four rows. Treat //go:linkname as a compiler implementation detail for the Go runtime itself — not a tool for application deployment.