Given a file lib.go:

package lib

func F() int { return 42 }

and main.go:

package main

import "./lib"

func main() { println(lib.F()) }

The following command sequence prints 42 as expected:

$ go tool compile lib.go 
$ go tool compile main.go
$ go tool link main.o
$ a.out
42

If one now changes 42 to 43 in lib.go, the following command sequence still prints 42:

$ go tool compile lib.go 
$ go tool link main.o
$ a.out
42

rather than 43. The issue is (presumably) that lib.F() got inlined and there's (apparently) no check in the linker that lib.go changed.

While not surprising to an initiated user, this is surprising to an unsuspecting user. Ideally the linker, or then the initialization code should check that a compiler package we link again (or that we initialize) is the same that we compiled against. This could be done with some fingerprint of sorts, perhaps computed on the export data only.

I suspect scenarios can be created where the linker succeeds and the program crashes (because a data type changed in lib.go and main.go wasn't recompiled).

This behavior is no different from C/C++ where we have "independent" compilation: as long as the linker finds the matching symbols, it doesn't care whether they are referring to the same entities that were implied in the source code - hence the independence.

Go should properly implement "separate" compilation: packages can be compiled separately, but correspondence to source code should be enforced.