And when Rob Pike decided to create Go from that compiler, he just got rid of headers.

Because the Go team did the right thing by adopting modules, which are as old as C in the computing world.

What do you mean by "modules" here?

Go actually calls them packages.

I just prefer the term modules, as it was introduced by Mesa and CLU in the 70's.

Only languages based on C's primitive toolchain rely on basic separate compilation of translation units with textual includes for symbol definition.

Modular languages, that make use of better toolchains, couple the concept of separate compilation, with strong type checking across compilation boundaries and compiler managed metadata for the exported symbols.

Thanks for the explanation. Do you think the idea of implementation/interface separation, that C and Java allow easily, is also better in Go?

I didn't got your question.

Java packages are not that different from Go packages, in terms of CS concepts.

Except for the set of issues that are debated to death about Go, the language is quite modular in Mesa tradition.

Given Oberon's influence in Go's design[1], maybe you will find these books interesting,

From http://www.inf.ethz.ch/personal/wirth/ check "Algorithms and Data Structures", "Project Oberon", "Compiler Construction".

From http://ssw.jku.at/Research/Books/ check Object-Oriented Programming in Oberon-2.

Linking is a separate step from compiling. It's a lot easier and clearer to keep that distinction. Of course, it's not as convenient, which is why I've fallen for the lure of pragma's in the past - but at some point, it will come back to bite you in the behind (wrong library linked, no library linked because of unusual combination of preproc variables, etc).

Microsoft's MSVC has this feature too:

http://msdn.microsoft.com/en-us/library/7f0aews7.aspx

Some libraries do the same in Visual Studio, e.g. Boost. But you'd have a hard time finding the exact library name to link against there as well.