When designing Go, we wanted to make sure it wasn’t overly ASCII centric, which meant expanding the space of identifiers out of the limitations of 7-bit ASCII. Go’s rule — that the identifier character must be a letter or number defined by Unicod — is easy to understand and implement, but also limited. For example, combinatorial characters are excluded by design, which excludes some languages, such as Sanskrit.
This rule has another unfortunate consequence. Because exported identifiers must begin with a capital letter, identifiers created from characters in some languages cannot be exported by definition. The only solution at the moment is to use a language like X Japanese, but this is clearly not satisfactory.
Since the earliest versions of the language, people have considered how best to extend the identifier space to accommodate programmers in other native languages. Exactly what to do is still an active topic of discussion, and future versions of the language may be more liberal in defining identifiers. For example, it might adopt some of the ideas in the Unicode organization’s identifier recommendations. Whatever happens, it must be done in a way that is compatible (or extended) with case to determine visibility of identifiers, which remains one of Go’s most popular features.
Currently, we have a simple rule that can be extended without breaking the program, which avoids the errors that are sure to be caused by rules that allow ambiguous identifiers.
Golang golang.org/doc/faq#uni…