Favorite comment, apparently to a C++ fan that was horrified by the fake angle brackets. "MaybE_Tree • 5d c++ allows 0-width spaces in variable names. Where's your god now?"
Unicode code comments make obvious sense if the software company is e.g. Chinese.
And allowing Unicode characters inside string literals makes obvious sense as well. It lets you have string literals which are, well, literal, rather than full of escape codes.
Unicode identifiers can make some sense for the same reason that comments do; often you'll want to just name something after some un-translatable concept from your own language, but even if you "romanize" the word, it might still require accents—making it Unicode!—to be that word, instead of some other word. (Pinyin and ASCII-/\w+/ do not get along.)
---
Separately, the devil's advocate position: Unicode identifiers for function names or operators are just plain fun, if your keyboard lets you write them easily. I'm surprised there's no modern equivalent of APL created to take advantage of the symbols you can write easily in macOS using Alt, Alt+Shift, or Ctrl+Cmd+Space.
(I once designed a Markdown variant that used these characters instead of ASCII ones. It also expected the use of IME-inserted smart quotes in the text, and compiled the opening ones to <q> and the closing ones to </q>.)
Comments and strings, yes. And even though, non-english comments is considered bad practice at the non-english-but-international company I currently work for.
In identifiers? No way in hell. ASCII is small and well known and yet has its share of subtleties between \r \n \t and whitespaces and case-sensitiveness.
The main point of ASCII is that it is really, totally, viewable without any surprise. Most programming fonts will be unambiguous, and won't make one letter appear like another: oO0, iIlL|1
Also, you can make monospace fonts for ASCII. One character can occupy a predictable space on screen.
Unicode is another level totally. Not only do tons of glyphs look similar but also some of them are hidden, some of them reverse the order of the flow (LTR) some modify others, some (like emojis) are supposed to not be easily colorable. And of course, d̕ia̻̟̮c̨̤͚ri͍͕̪t̘̫̺͎̰̘i̯̫̱̻c̵͔̙̮̻̫͕̝s͉̹ make character expand up and down (I only went smoothly on this one, use http://www.marlborotech.com/Zalgo.html to realize the magnitude of this mess)
I once had to deal with a program written in Japanese, luckily in UTF-8. I was very tempted to propose patches using accentuated French and emojis.
I'll be a proud defender of my beautiful French language any day, but as a programmer, we have the incredible luck of having more or less standardized on a language and a simple encoding. We should see that as an asset, not as a limitation.
Imagine if Linus commented his code in Finnish. We can't have that.
I seem to recall reading an email regarding the policy of only using English words for Linux kernel variables etc. Something about avoiding having to deal with stuff that looked like street signs from ryleh.
No, it's scary. I liked the comment because it highlights that this isn't just a golang problem. Nor is it just a code problem, lots of recent stories of browsers not knowing quite when to show unicode chars or punycode in the omnibox, for example.
Not sure that disallowing it everywhere is the answer either. As an American that speaks only English, I'm probably not the best person to answer what is the right approach.
Because if you speak only English and are surrounded by vast stretches of land on every side of you where people mostly only speak English, you don't feel the pain. (And seriously? One reason most code might be written only in English is due to the systemic bias of programming environments that only support English.)
Edit: I remember distinctly how some of my colleagues were touting the possibility of using emoji in Swift code as identifiers as a feature. The whole premise sounded more like Poe's Law to me then, too.
