> Angle brackets require unbounded parser look-ahead or type information in certain situations

So they want to avoid angle brackets so they can efficiently parse source code.

- What situations could cause the look-ahead to be unbounded?

- How does the Go parser's implementation differ from those of the languages I'd previously listed which all also have angle brackets for comparison (and bit shifts, as another commenter pointed out) while apparently avoiding unbounded look-ahead?

- What challenges does the Go parser present when trying to adapt it to follow patterns more like those from the other languages' parsers?

- I'm assuming "unbounded" here doesn't mean "it could take unlimited time" but rather "it could incur non-negligible compile-time penalties;" do the benefits of a slightly-quicker compilation (which has nominally no impact on runtime performance) outweigh improved readability?

> - How does the Go parser's implementation differ from those of the languages I'd previously listed which all also have angle brackets for comparison (and bit shifts, as another commenter pointed out) while apparently avoiding unbounded look-ahead?

I think parsing Java or C++ requires unlimited lookahead.

In fact, I think D is the only one using () as well.

  template TCopy(T)
  {
      void copy(out T to, T from)
      {
          to = from;
      }
  }

  /* … */

  int i;
  TCopy!(int).copy(i, 3);

> AFAIK, Golang assigns no special syntactic meaning to angle brackets beyond comparison operators

Go has also got bit-shift operators << and >>, which wouldn't interact well with angle-bracket notation.

So do Java and C++. This is a solved problem in parsing. The overall point that angle brackets make parsing more complex stands, but bit-shift arguments are irrelevant.