February 21, 2026

Schrödinger’s build: same code, new chaos

Are compilers deterministic?

Same recipe, different cake? Devs brawl over what “deterministic” even means

TLDR: The article argues compilers only spit out identical bits if every tiny input is frozen; otherwise, “same code” can look different under the hood. Commenters split between “behavior is what matters” purists and “your inputs are messy” realists, with jokesters roasting AI-flavored toolchains for extra drama

An essay asked the world’s most chaotic question: does the same code always bake the same binary? The author says “in theory, yes; in real life, not so much” because tiny invisible ingredients—timestamps, tool versions, even file order—sneak into the mix. One veteran recalls patching live Linux systems and watching the machine code change even when the program’s meaning didn’t. Cue the food fight. The loudest camp shouts: compilers promise the same behavior, not the same bytes. If your app acts the same, who cares if the instructions are shuffled? “That’s literally the contract,” fumes measurablefunc, accusing the article of chasing “random” noise like build dates.

Across the ring, pragmatists clap back: if you can’t lock down every little input, don’t expect identical output. nu11ptr sums it up like a weather report: the “storm” is the inputs, not the compiler. cyanydeez goes existential: humans can’t measure every variable, so the universe laughs at your “deterministic” dreams. Meanwhile, the peanut gallery adds spice: one commenter riffs on “vibe coding” and trust—users care if it works, not how it’s cooked—while another drops the line that had the thread cackling: “Not if they’re made by Anthropic…” Reproducible-builds fans link receipts and chant for deterministic recipes so two kitchens get the same cake, not just the same taste

Key Points

  • A compiler is deterministic with respect to its complete input state, but typical builds do not control all inputs, leading to differing outputs.
  • A formal input model includes source, flags, toolchain binaries, runtime, environment, filesystem, locale/timezone, clock, kernel behavior, and hardware/concurrency schedule.
  • Observed in practice (e.g., Ksplice with Linux kernels), output differences can arise from register allocation, pass behavior, and layout changes without semantic changes.
  • The compiler’s contract is to preserve semantics (observational equivalence), not to produce byte-identical binaries; reproducible builds are a stricter goal.
  • Numerous entropy sources (timestamps, paths in DWARF, locale sorting, filesystem order, parallelism, archive metadata, build IDs, network fetches, version skew, host differences, unstable pointer/hash traversal) can affect reproducibility.

Hottest takes

“Compilers preserve semantics. That’s the contract” — measurablefunc
“That implies the input isn’t deterministic, not the compiler” — nu11ptr
“Not if they’re made by Anthropic...” — Smalltalker-80
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.