I think they meant “type information is not available at parse time” (rather than “compile time”).

There is a longer and more precise description of the problem as part of this FAQ of the generics proposal:

https://go.googlesource.com/proposal/+/refs/heads/master/des...

…which includes an example and the statement “It is a key design decision of Go that parsing be possible without type information”.

Most (if not all) languages are compiled or interpreted in two stages: first the code is parsed (a.k.a. lexed, tokenized) to an internal representation (usually called "Abstract Syntax Tree", or AST), which just means translating something like ">" to "GREATER_THAN_SYMBOL", "5" to NUMBER, etc. and storing this in some data structure. This is also where you usually detect syntax errors like forgetting to use " to close a string and such.

In Go, you can do this fairly easily with the go/ast package.

Then you take the AST and do something with it. That something can be compiling the code, but also writing some sort of tooling like a linter, or identifier rename tool, or generate documentation from it, or whatnot. When compiling the code you need the type information, for a lot of other purposes you don't really care.

It's pretty valuable to keep the parsing as simple as possible; it makes it easier to detect errors, improves the quality of the error messages, and makes it easier to write tooling. It also keeps the code a lot simpler, easier to understand and modify, etc.