Why is the standard library's syscall package frozen, and what does golang.org/x/sys provide instead?

## The compatibility promise is the reason Go 1 promises that code which compiles today keeps compiling and behaving the same way on every later Go 1.x release. That promise is what makes upgrading Go boring, and it applies to every exported identifier in the standard library. Now look at what `syscall` contains: thousands of machine-generated constants, structs mirroring kernel layouts, and thin wrappers, all of it different per operating system and per architecture. Kernels add calls and flags continuously; the layouts of some kernel structs are not stable; and a wrapper whose signature was a good idea in 2012 cannot be corrected. Holding that surface unchanged forever, while also keeping it current, is a contradiction. The resolution was to lock the package down. The package documentation says so directly: it is locked, and code outside the standard library should migrate to the corresponding package in the `golang.org/x/sys` repository. Locked does not mean deleted or deprecated-to-removal — `syscall` still compiles, the standard library still uses it internally, and the identifiers it already has are still under the Go 1 promise. It simply stops growing. ## What golang.org/x/sys is `golang.org/x/sys` is one of the `golang.org/x` repositories: maintained by the Go team, developed in the open, but versioned and released as an ordinary Go module rather than as part of the toolchain. Its packages are: - `golang.org/x/sys/unix` — the Unix surface: system calls, errnos, `Stat_t` and friends, ioctl helpers, on Linux, macOS, the BSDs, Solaris and more. - `golang.org/x/sys/windows` — Win32 APIs, handles, registry, service control. - `golang.org/x/sys/plan9`, `golang.org/x/sys/cpu` (CPU feature detection). Most of it is generated from the platform's own headers and regenerated as kernels move, which is exactly the churn the standard library cannot absorb. ## What you give up by depending on it This is the part interviewers actually probe: 1. **It is outside the Go 1 compatibility promise.** The x repositories have their own, looser policy. Breaking changes are rare and telegraphed, but they are permitted. 2. **It is a module in your `go.mod`.** It appears in your consumers' module graph, in their dependency review, in their vulnerability scanning, and in their build reproducibility story. 3. **It tracks recent Go releases only.** Upgrading `x/sys` can raise the minimum Go version your module needs, which propagates to everyone importing you. 4. **It is per-platform by construction.** `x/sys/unix` does not build on Windows at all, so importing it forces the per-GOOS file discipline on your package. Against that: it has no transitive dependencies, it is pure Go on most targets, and the alternative — hand-writing raw syscall numbers and struct layouts yourself — is far worse, because the numbers vary by architecture and the layouts vary by kernel. ## Choosing between them in practice - The call or constant already exists in `syscall` and you only target platforms where it is correct: **keep the standard-library import.** There is no prize for churn. - You need something `syscall` never got — a newer `openat2`-era call, a flag added after the freeze, a struct field the frozen definition lacks: **take `x/sys`.** - You need Windows APIs beyond the handful `syscall` exposes: **`x/sys/windows`, always.** - You are writing a library other teams import: take the dependency deliberately, confine it to one internal package, and treat the version as a decision rather than an automatic bump. ## The thing that is not different Both packages present the same shapes: an `Errno` type that satisfies `error`, named errno constants, functions that return `(n int, err error)`. `x/sys/unix` has its own `unix.Errno`, `unix.ENOENT` and so on, so a codebase mixing both can end up comparing an errno from one package against a constant from the other. On Unix those types are aliases of the syscall ones in practice, but the honest habit is to pick one package per package-worth of code and stay in it, so that `errors.Is` targets and the constants you compare against come from the same place.