I also like this comment from the almost-empty /r/ProgrammerHumor/ submission linking to that thread:

  Gives new meaning to the phrase "Native apps"

To be fair I suspect this part of that sentence explains the reason for choice of these special character:

From Go's perspective, that's just one long identifier.

The designer was using those characters to trick the Go compiler which I then suspect means things like go format would also continue to work.

Then the designer could easily create a pre-processor that translates those placeholders characters as a way of providing some sort of generics in Go.

So in reality this was quite a good solution as I can imagine coming up with a solution that broke go format would have been a real pain to use.

> So in reality this was quite a good solution

Yes, I do not understand why people find this so hilarious. It's a clever choice.

Because they look like normal angle brackets. Unless you are in on the secret, you won’t understand why your code doesn’t work.

Easily fixed by using ᑅ ᑀ, ᕙ ᕗ, or ᗕ ᗒ.

For some values of "easily" and "fixed".

Maybe it’s just at the companies I’ve worked at, but replacement vars are usually double underscores:

    Here is __REPLACE__ var.

That is a clever choice.

A wise choice would be simply adding double underscores between the identifiers.

The fact that the author needs to explain how it works on an Internet forum is evidence it was neither a clear nor clever choice, but a probably a bad choice.

Clear is better than clever.

I like to know this:

> c++ allows 0-width spaces in variable names. Where's your god now?

I imagine many languages do the same, but I lack the will to test it.

Anyway, of course, it would be more correct if it was considered whitespace... And I bet anything parsed in Haskell or Perl6 does such.