Languages like C++ require a symbol table to parse properly, because some constructs are syntactically ambiguous if you don't know whether a given token represents a type, a function or a variable.
The main concrete example that I'm aware of is that declaring functions and constructing values both use parentheses:
int foo(3); // creates an integer called foo with value 3
int bar(int); // creates a function called bar that takes an int and returns an int
To parse this, you have to know that
int is the name of a type and
3 is not. Because of user-defined types, in general you cannot know whether a given token is a type name unless you have a symbol table containing all types the parser has seen up to this point. Note that the infamous "Most Vexing Parse" is closely related to this particular ambiguity.
The author you've quoted is most likely claiming that the Go language has no ambiguities like this, and thus can be parsed correctly without a symbol table. If you look at the official Go language specification, you'll notice pretty much everything about the syntax comes with an EBNF definition. I haven't read through it thoroughly, but it seems likely that Go's syntax is an actual context-free grammar, not merely approximated by one, which is pretty nice compared to C++.
>>) and for that purpose parser builds symbol table on fly? Something along those lines?